宫论项目开发记录

2024年11月20日
1、在超时关闭退款订单后，会触发identify_timeout_close通知场景消息。通知时会通过push_data数组携带以下参数：首先是type，表示退款方式；接下来是amount，指退款金额；reason则表明退款原因；payment为原支付订单号（主键ID值）。此外，还包括当前设备的IP地址（ip）、用户代理信息（ua）以及用户指纹信息参数（fingerprint，用于用户操作时提供，系统操作则不提供）。
2、考虑到鉴定订单关闭渠道多达三种（鉴定人主动关闭、鉴定师主动退回操作、系统超时自动关闭），如果为每一种情况单独集成通知，不仅维护工作繁重，还会导致集成过程复杂、耗时。因此，特意设立了一个全新的通知场景【identify_close】。这一场景将所有与鉴定订单关闭相关的通知统一通过此钩子进行处理，旨在简化管理流程，提升维护效率，同时有效减少开发工作量，以保证系统的高效运作。
3、新增了钩子：xc_identify_close_hook（鉴定订单关闭钩子）。该钩子将仅在完成鉴定订单退款时触发，包括退款中和等待手动退款的状态。为了实现这一功能，钩子需要传递两个变量参数：1、id（鉴定订单编号），用于识别需要执行关闭业务逻辑的具体订单；2、type（关闭订单类型），其固定值包括【buyer：鉴定用户、 seller：鉴定师、 system：系统】。通过这两个参数，能够精确地执行相应的业务逻辑。
4、在鉴定订单完成并退款之后，缓存清理的操作和行为不再嵌入退款流程中。这是由于缓存机制存在很大的变动性，如果将其代码写入退款逻辑中，会导致后续的维护变得复杂。现在，通过使用 xc_identify_close_hook 钩子来统一处理缓存相关的操作，这样一来，无论是缓存的变动还是维护需求，都能实现快速响应和及时更新。需要注意的是，在鉴定订单完成退款后，订单状态的回调操作涉及到计数器、缓存和通知的处理，这些操作均由关闭钩子来完成，从而确保了处理的一致性和高效性。
5、针对鉴定订单关闭事件钩子的优化处理方案进行了调整，将原本传递的第二个type变量修改为传递refund退款ID主键。这一变化基于这样一个逻辑，即触发订单关闭事件必然是由于已完成退款申请（即生成了对应的xc_refund记录）。因此，所需的通知参数可以直接从鉴定表和退款表提取，从而有效减少参数的传递处理步骤，以及简化二次参数封装的繁琐过程。此举不仅提高了处理的效率，还有助于降低系统的复杂性。
6、在触发xc_identify_close_hook钩子后，系统会调用xc_query_identify以获取本次鉴定的订单信息，并将返回的结果存储在identify变量中。同时，系统还会调用xc_query_refund来获取相关的退款记录，并将结果保存在refund变量中。在成功读取两个数据表后，接下来将使用empty函数进行检查，以确保identify和refund两个变量都成功获取了相应的记录。如果任一变量未能正确获取，则系统将返回false，并中断后续的执行流程。
7、鉴定订单已成功关闭。在使用统一查询方法获取鉴定订单表和退款订单表的记录时，会将缓存标记为true，以确保返回的数据是直接从wpdb读取的，而非依赖于之前的缓存结果集。此外，在成功获取鉴定订单表的记录后，系统还会通过delete_rides_meta功能清理query_identify的查询缓存，从而确保后续的查询始终可靠有效。
8、对于宫论query订单查询接口，处理缓存更新机制进行了重要调整。当需要更新缓存（例如订单返回要求拒绝缓存）时，不再通过redis_key值进行内容更新，而是采用update_redis_meta方法，直接以redisk​ey值进行内容更新，而是采用updater​edism​eta方法，直接以sql_result['id']和$sql_result['number']作为键名发起缓存删除操作。这一改进有效避免了清理了A的缓存但未能及时更新B的缓存的问题。例如，在查询支付订单时，通过id主键进行查询。如果拒绝缓存，将直接通过wpdb获取数据并更新相应id主键的缓存。然而，支付订单查询还支持商户单据查询，这就导致了商户单据缓存未能及时更新，造成了数据混乱。新版的缓存处理机制成功解决了这一问题，确保了各类缓存的同步更新，提升了系统的稳定性与准确性。
9、由于对统一查询接口的缓存更新进行了优化，现在发起 xc_query_XXX 查询时，不再需要专注于缓存更新与同步处理。只需将第二个变量标记为 true，即可自动完成缓存的清理。对于涉及写操作的订单状态变更，用户只需重新执行一次订单查询，系统将自动更新查询缓存，确保前端获取的订单信息真实有效。此外，关于订单关闭钩子的处理，已移除 delete_rides_meta 的手动更新步骤，以简化流程。
10、新增了鉴定师字段：time_out（超时未响应订单）。当鉴定订单的关闭钩子触发时，系统将获取退款记录表。如果退款方式为系统退款，意味着该订单因为鉴定师超时未响应而关闭，因此系统需对鉴定师进行相应的处罚或其他处理。这一部分目前属于预留事件，未来将进一步研究具体处理方案。目前的主要功能是读取鉴定师记录，并根据time_out字段记录超时次数。需要注意的是，平台将在后续开发一个页面，用于展示鉴定师超时未响应的订单数量，同时执行定期清理计划。如果用户在30天内超时未响应的次数超过X次，系统应及时对鉴定师采取措施，以确保不影响用户体验。
11、宫论统一订单查询钩子: 新增了鉴定师查询方法xc_query_expert。该方法用于根据给定的用户 ID 检索鉴定师信息，通过从数据库或缓存中获取数据来实现。流程中首先检查 Redis 缓存是否存在有效数据，若缓存中没有数据或指定跳过缓存，则会直接访问数据库进行查询。需要注意的是，参数$user_id为用户 ID，用于精确查找对应的专家信息。特别说明，该查询功能仅支持基于user_id的查询，而不支持通过ID主键进行检索，因为user_id即为唯一主键。此外，该方法同样具备缓存机制的支持，以提高查询效率。

2024年11月19日
1、在通过新版退款钩子进行支付宝退款请求时，系统会通过ctr-catch机制来捕获可能出现的异常或错误。这些错误通常由SDK返回的错误信息或支付宝返回的异常情况引起。一旦catch机制捕获到异常，系统会自动使用xc_log_error_warn记录下错误日志。同时，将通过meta功能记录本次退款异常的详细信息，包括错误发生的次数（number）、错误的具体原因（getMessage）、以及错误发生的时间。这一流程确保了错误的透明和可追踪性，有助于后续的分析与处理。
2、为避免系统退款过程中因反复错误导致的死循环，规定当退款请求的来源系统符合条件【$refund['type'] == 'system' 】且失败次数达到后台设定的上限时，将会主动标记该订单为退款成功。此时，系统将执行一系列退款成功后的操作逻辑，包括触发支付数据表中的回调、发送相关通知事件以及将信息写入退款记录表。不过，值得注意的是，这一措施具有一定的风险，我们还需在后期进行详细的风险评估，以确保此策略的安全性和可靠性。
3、新版退款钩子【xc_payment_refund_news_hook】已完成封装处理，在此过程中增加了多项拦截机制以确保请求环境的安全性和可靠性。同时，对整个退款流程进行了优化，提升了日志监听器的功能，使每一步操作都可以被溯源跟踪，从而确保资金流动的安全。新增的订单退款表大大方便了对退款流向的溯源和查看，进一步提升了系统的透明度和管理效率。
4、针对鉴定订单的超时自动关闭任务，现在系统会定期检测鉴定订单是否已超出规定的处理时间（后台默认设定为48小时）。若订单确实已超时，系统将从鉴定表中读取对应的支付订单ID，并检查该订单的支付状态是否为正常支付状态。如果符合条件，系统将通过新版的统一退款钩子发起退款请求。在进行退款操作之前，系统会先配置一个有效期为300秒的退款锁，以防止重复退款请求的发生。如果检测到退款锁已存在，系统将使用continue语句退出当前进程，避免重复处理同一笔订单。
5、支付定标【xc_pay】系统中新增了两个订单状态：fail_refund 和 wait_refund。这两个状态在一定程度上表明平台已经完成了结算，即支付订单已经标记为退款成功，并且在SDK发起退款请求时，鉴权判断已符合退款要求。然而，由于对方账户的问题，如账户被冻结或被风控，或由于支付渠道的原因，导致退款到账存在延迟。此外，这类情况也可能需要手动打款操作来完成退款。因此， fail_refund 表示系统尝试退款失败，而 wait_refund 表示系统正在处理退款过程中。
6、为了确保超时鉴定订单的退款能够顺利进行，将会创建一个详细的refund退款数组信息，其中包含以下关键参数：首先是$refund['id']，即支付订单号，该参数可以通过鉴定表中的payment字段获取；其次是type，这里标记为system，表示此次退款请求是由系统自动发起的；接着是amount，也就是本次退款的金额，由于鉴定订单需要全款退还，因此可以直接从支付表中的pay_amount字段获取该金额；然后是reason，鉴于订单因为超时未处理，需要自动退款，因此此处标明为“鉴定订单超时未处理自动退款”；最后是refund_key，用于标识此次退款请求的唯一令牌，以确保退款过程的安全和准确。
7、在完成退款数组的封装后，即刻执行 xc_payment_refund_news_hook($refund) 钩子，以发起退款请求。该钩子的返回结果将存储在变量【$refund_hook】中，并对其进行验证。如果该变量为空，或者返回数组中的 code 值不等于0，则表明此次退款操作失败。在这种情况下，将通过执行 continue 语句退出当前进程。对于退款失败的原因，将通过退款钩子日志来进行处理和记录，以便后续分析和解决问题。
8、在系统中新增了针对退款状态变更的处理机制，优化支付订单缓存管理。当前，支付订单会通过xc_query_payment方法生成缓存，但一旦出现退款情况，必须清理该缓存以确保数据的准确性。具体操作是利用delete_redis_meta函数删除对应的缓存键值，格式为：query_payment:" . $id，其中id代表支付订单的唯一标识。需要特别注意的是，只要支付订单状态发生任何变化（不仅限于退款成功），都会触发缓存删除操作，以防止其他应用场景中因使用过期缓存数据而导致的错误。这一举措提高了系统数据的一致性和可靠性。
9、在鉴定订单退款成功后，首先需要将原鉴定订单表的状态标记为3，即超时未鉴定，被系统关闭，以防止后续的定时计划再次发起重复的退款关闭操作。在完成状态回调之后，系统将立即调用delete_redis_meta函数，清理鉴定订单的查询缓存，以确保后续页面读取到的缓存数据不再显示为待鉴定状态。需要特别注意的是，由于缓存机制的设计特点，任何订单状态的变化都必须及时主动地进行更新，才能确保系统的可靠性和数据的一致性。
10、对支付订单表和鉴定表的缓存清理机制进行了优化。这两个表的查询缓存并非采用单一模式，而是同时支持【鉴定主键、鉴定编号】和【支付主键、支付单号】的缓存设计。因此，在进行缓存清理时，不仅需要清理主键的缓存，还必须同步清理鉴定编号和支付单号的缓存，否则在极端情况下，可能会导致缓存数据仍然存在，影响系统的准确性。特别需要注意的是，缓存的清理动作必须严格遵循统一订单查询接口的缓存设计规则，以确保缓存清理的有效性和完整性。
11、全局推送通知管理配置新增场景【鉴定】订单超时未处理关闭。具体而言，当鉴定单超过系统规定的处理时限而仍未得到处理时，系统将自动触发退款计划。完成退款后，系统会对该鉴定订单执行关闭操作，并相应触发通知，将订单取消的消息告知鉴定用户，同时说明取消的原因。该通知场景的标识为：identify_timeout_close。此通知涵盖了鉴定师和鉴定用户两个角色，因此在处理通知时需进行相应的身份判断和处理。

2024年11月18日
1、在执行微信或支付宝退款操作时，系统会自动触发【wxpay_payment_success_log或alipay_payment_success_log】日志事件，记录本次退款行为的详细信息。这一日志记录包括服务商返回的完整JSON数据包，保持数据包的原始状态，不进行任何调整或修改。为了便于管理和查找，日志以时间为单位进行归档，按年月日分类存储。例如：微信支付的日志文件会被存储在类似于“wxpay/2024-11-18.log”的路径下。
2、在支付系统的日志记录功能中，新增了对支付回调日志的支持，能够有效记录支付和退款的详细信息。日志函数现在包含一个名为refund的变量，并默认设置为false。这意味着，除非明确指出是退款请求，否则所有记录都将被视为支付记录。在处理退款时，只需将refund变量标记为true，即可准确记录这类交易。此外，为确保日志中的中文内容在转化为JSON格式时能够正确显示，系统在进行JSON编码时采用了JSON_UNESCAPED_UNICODE选项。这一优化提升了数据处理的准确性，确保所有字符在记录存储过程中都不会因为编码问题而导致信息缺失或错误。
3、在通过统一接口发起支付宝退款操作后，会将结果转换为数组并存储在【refund_result】变量中。接着，使用empty函数对该变量进行检测。如果结果为空，说明接口出现了异常情况。如果结果不为空但$refund_result['code']的返回值不等于10000，则表明此次退款操作失败。在这种情况下，将通过xc_log_error_warn函数记录错误日志，并释放当前的锁，同时返回code=1以终止后续处理。
4、当支付宝退款请求的返回代码为【10000】时，表示该退款请求已经成功发起并被支付宝受理。然而，退款结果可能存在不确定性，需要根据$refund_result['fund_change']的值进行进一步判断。值为Y时表示退款已成功；若为其他状态，则说明退款失败或仍在处理中，需要采取进一步措施来解决。
5、在通过退款接口成功请求支付宝退款后，需要对原支付订单进行更新，将订单状态标记为退款完成。具体操作步骤包括构建一个支付订单退款信息数组，参数有：state（用于标记支付订单已完成退款）、refund_amount（此次退款的金额）、refund_time（发起退款的时间）、return_content（记录退款时间和原因），以及meta（自定义字段参数）。随后，使用xc_update_sql语句发起支付订单的更新请求。需要注意的是，支付订单回调动作不会进行错误监听和返回处理。
6、在退款成功后，系统将自动触发【xc_payment_refund_ok_hook】回调动作钩子，该钩子主要负责下达退款订单的通知。退款过程会携带退款数组信息，因为在大多数情况下，这些通知都是异步触发的，因此必须通过退款数组的信息来获取本次退款订单的关联详情，比如付款人、收款人及支付订单的主键等。具体的退款回调通知需要根据不同的支付场景进行规划和处理。在完成消息通知的下发后，系统会通过xc_unlock来释放相关的锁，以确保后续操作的顺利进行。
7、在完成退款通知的发送后，将使用 xc_insert_sql 插入一条退款记录。插入的信息为【refund：以数组结构封装好的退款数据】。在此基础上，加入如下三个字段信息：首先是 $refund['status']，该字段为1表示本次订单退款成功，也可以填入其他状态以反映不同的退款结果；其次是 $refund['success_time']，该字段用于记录此次退款的具体时间，便于日后的追溯和查证；最后，使用 JSON 格式在 $refund['success'] 字段中保存退款返回的数据包信息，确保所有相关细节被完整存储。在完成这些数据写入至退款表的操作后，整个退款过程即告完成。最终会返回 code=0 以及 msg=订单退款成功，以确认退款操作已顺利执行。
8、在处理支付宝退款时，有时会遇到退款成功但fund_change返回并非Y的情况。这意味着退款已经被成功发起并且平台也已接收，但由于账户异常等原因，此次退款请求需要延迟通知。为了确保资金安全，在这样的情况下需要进行特别处理。处理方式包括以下两种：首先，可以接收支付宝的异步通知，并根据通知的结果来判断最终的处理状态；其次，可以使用定时计划，定期检测付款状态的变化。不论采取何种处理方式，在最终确认退款成功之前，都应将订单状态标记为“待处理”、“处理中”或“退款中”，以便后续跟进和管理。
9、当支付宝退款订单处于"退款中"状态时，原支付订单的状态将被标记为【wait_refund】。同时，会将以下字段信息写入待退款支付订单中：1）【meta】：包含退款的自定义字段参数；2）【refund_order】：用于识别的退款订单编号，是通过number继承下来的；3）【refund_amount】：本次订单的退款金额；4）【refund_time】：发起退款的时间；5）【return_content】：退款的原因说明。这些信息会在退款过程中提前记录，以便在回调接口确认退款成功时，仅需更新订单状态即可，无需再处理其他字段。
10、在处理支付宝订单的退款时，即使退款状态显示为“退款中”，系统也会将其视为退款成功，并触发【xc_payment_refund_ok_hook】这一退款回调通知。退款通知中会特别提醒用户，退款金额将在24或48小时内到账，如有任何疑问，可以联系官方客服进行处理。此外，对于处于待退款状态的订单，系统也将主动通过xc_unlock机制解除订单锁定，并结束此次退款流程。
11、当支付宝订单的退款操作正在进行时，即便处于“退款中”的状态，系统也会通过xc_insert_sql函数将退款记录写入数据库。不过，此时的记录不会包含success和success_time字段的具体内容。同时，订单的状态会从“1成功”变更为“2退款中”。同时，当前退款的信息会以JSON数据包的格式记录在$refund['fail']字段中。一旦退款记录表生成成功，系统将返回一个状态码code=0，并提示消息【订单退款请求已成功提交\n，如果超过三天未到账，请联系平台客服进行处理。】

2024年11月15日
1、在进行退款操作时，一旦退款成功，系统将新增一个字段：refund['success_time']，用于标记此次退款成功的具体时间。虽然余额退款通常是即时到账的，但对于微信和支付宝这类第三方支付平台，其退款确认常常存在一定的延迟。许多情况下，必须通过异步接口或主动查询接口来确认退款是否真正成功。因此，增加这个字段十分必要，以便准确记录实际的退款完成时间。
2、当微信或支付服务商返回退款成功信息时，系统会在插入退款记录表之前，封装一个名为【success】的字段，并包含服务商返回的完整接口数据包。这个数据包中包含诸如鉴权参数、支付信息以及回调结果等关键内容。之后，该数据包会被转化为JSON格式并存储到数据库中。这种存储方式不仅确保了信息的完整性，而且在发生退款纠纷时，可以通过该信息包进行详细的比对和核查。需要注意的是，这个字段只有在使用微信和支付宝进行交易时才会存在，若是使用平台余额进行处理，由于不依赖外部服务商，所以不会返回这样的记录。
3、当在微信或支付宝执行退款操作时，如果服务商返回异常或失败的信息，这些结果将被记录在【fail】字段中。该字段详细记录了鉴权数据包、退款失败的原因等信息。这些数据以JSON格式存储，并通过JSON_UNESCAPED_UNICODE选项进行转换，以确保中文字符不被转义。记录的错误信息是完整的，并将在财务审核期间被解析和展示，以便查阅和分析。
4、status退款状态字段主要用于记录订单退款的实际进展情况，并根据不同的退款状态执行对应的回调处理。具体来说，状态值1表示退款成功，状态值2表示退款处理中，状态值3表示退款失败。这个字段尤其用于微信或支付宝渠道的退款处理，根据服务商返回的结果，系统会将相应的状态写入退款订单表。当新建退款订单记录时，系统会默认写入refund['status']，默认为1（退款成功）。如果通过接口获取到的状态表明退款未成功，则系统会根据实际情况写入状态2或3，以确保退款过程的准确追踪和处理。
5、增加异步错误处理检测机制，当微信发生退款异常的时候，会通过$meta['refund']['fail']记录失败原因，并使用meta['refund']['number']记录错误发生的次数。如果错误次数超过后台设定的阈值，系统将自动触发日志报警机制。这样的平台设计能够确保管理员在接口返回异常错误时能够迅速获取相关信息，便于及时查找和解决问题，从而提升平台的稳定性和用户体验。
6、系统退款保护机制：在进行异常捕获时，如果退款请求是由系统自动计划执行的，系统将通过$meta['refund']['fail']属性来检测该退款的失败次数是否超出后台设定的【xc_pay_retund_number_fail】阈值。一旦检测到失败次数超过该设定值，系统会将该订单标记为需要人工干预处理。这一机制的设计旨在防止系统陷入循环反复执行失败的退款请求，从而保障系统的稳定性。值得注意的是，此时订单虽被标记为退款成功状态，但实际上仍需人工进一步核实和处理。
7、为防止重复生成退款订单，现已在 xc_payment_refund_news_hook 钩子中新增了一项检测处理。每次获取到支付订单数据信息后，系统会利用 $payment['id'] 构建一个 WPDB 查询语句，以确认 xc_refund 数据库中是否已存在相应的退款订单记录。一旦确认已有记录，系统将终止生成新退款订单，并提示【已有退款订单记录，拒绝生成退款订单信息】，从而有效预防重复退款订单带来的潜在风险。
8、统一订单退款钩子【xc_payment_refund_news_hook】已圆满完成微信支付退款请求的处理。在全面完成所有参数的安全检查后，系统通过SDK正式发起退款请求。根据支付服务商返回的处理结果，系统将执行相应的业务处理，并作出必要的状态回调动作。整个退款过程全程有日志记录，确保操作的每一步都可以追溯和跟踪，保障退款流程的透明和安全。
9、支付宝的退款流程是通过宫论的统一退款接口完成的，这与微信的退款流程基本类似。首先，需要加载xc_sdk_composer项目包，然后使用xc_payment_config_hook函数获取支付配置的参数信息。在这些准备工作完成后，通过调用【Pay::alipay()->refund】接口发起退款操作。在整个退款过程中，采用了try-catch机制来捕获可能出现的异常情况，从而减少因错误导致执行过程中的意外中断，提高了系统的稳定性与可靠性。
10、发起支付宝退款的时候，会封装数组【refund_result】数组，里面包含以下参数【refund_amount：本次的退款金额、out_trade_no：原支付订单号（需要鉴权处理）、out_request_no：系统生成的退款编号，通过$refund['number']来获取】、refund_reason：本次退款的原因，用户可以见到】在完成该数组的封装处理后，将执行$refund_result->toArray来发起退款请求，然后根据执行的返回结果，返回对应的信息。
11、钩子脚本函数库集成了【wxpay_payment_success_log】和【alipay_payment_success_log】两个专用的支付日志记录函数。这两个函数负责将支付事件的详细信息以JSON格式记录在日志文件中。这些日志文件的命名基于当前日期，以便于归档和检索。如果当天的日志文件已存在，新生成的数据将会被添加到文件的最上方，确保最新信息的高效展示。这一日志记录功能不仅支持常规的支付回调，也兼顾退款操作的记录需求，只需在数据中将refund变量设置为true即可准确标识退款事件，方便日后审计和问题追踪。

2024年11月14日
1、新版的统一退款钩子在处理微信退款时，通过【宫论支付SDK】发起并执行。具体操作步骤包括：首先加载composer的项目包，然后读取\Yansongda\Pay包。在此基础上，利用xc_payment_config_hook函数获取后台设置的支付配置参数。接下来，通过调用wechat()->refund方法来构建微信退款请求。需要特别注意的是，退款过程中涉及到一系列复杂的证书及其鉴权问题，事前必须配置好环境，以确保退款流程的顺利进行。
2、在发起微信退款请求时，需要构建一个订单数组作为退款请求对象。这个数组包含以下字段：首先是out_trade_no，即原支付交易对应的商户订单号；接着是out_refund_no，代表商户系统内部唯一的退款单号，以确保每次退款请求的唯一性；然后是reason，用于在退款信息中体现具体的退款原因，以便于记录和查看。最后是amount，这是一个包含退款金额信息的对象，其中需要明确填写本次的退款金额，以及原订单的支付金额，并通过currency参数标识该金额为人民币（CNY）。这些信息共同构成完整的退款请求数据包，确保退款过程的准确性和透明度。注：这些参数都通过退款数组和和支付订单数组来获取。
3、在完成微信退款数组的封装后，会执行宫论统一退款SDK【Pay::wechat()->refund($order)】，并将结果存储在变量refund_result中。接下来，利用toArray()方法将结果转换为数组格式，并采用is_array和isset两个函数来检测返回结果的有效性和可靠性。由于退款状态可能会有多种变化，因此需要对每种状态进行仔细甄别和处理，以确保执行结果的准确性和可靠性。这种全面的状态检验方式旨在保障每一笔退款操作都能无误并及时处理。
4、微信退款状态一共有四种：1、当返回的状态不是标准数组或者为空时，通常表示接口请求出现了异常。2、CLOSED：服务商返回接口显示退款已关闭，并拒绝操作。这通常是因为订单已退款或退款申请超过了系统许可的时限。3、ABNORMAL：表示退款异常，可能原因是绑定的银行卡被冻结，因而需要平台手动处理退款。4、PROCESSING：退款请求已提交并正在处理中。5、SUCCESS：表示退款已成功完成。注：只要返回的状态是ABNORMAL、PROCESSING或SUCCESS，均可视为退款成功。因为这些状态表明退款请求已被受理并符合退款条件，只是可能涉及延迟或者需要手动打款处理。
5、微信退款：前端返回提示信息如下：1、退款失败：接口返回的内容包含错误，无法正常处理。2、退款失败：状态显示为"CLOSED"，退款申请已关闭。3、订单退款请求已成功提交。若超过三天仍未到账，请联络平台客服协助处理。4、订单退款请求已提交，需要平台手动介入完成退款，通常在72小时内处理完毕。5、订单退款成功。这些提示信息是根据服务商接口返回的参数提供的，旨在方便用户理解退款状态并及时采取相应措施。
6、为提高溯源操作的效率，我们在退款发生失败或异常时，会将详细信息写入refund日志。此日志记录退款失败或异常情况，并自动触发报警机制，提醒管理人员及时介入处理。具体记录的信息包括【退款时间、退款渠道、错误标识、退款单号】等，确保在调查和解决问题时可以快速定位问题源头。所有通过统一退款接口发起的退款请求，只要未成功处理，都会详细记录其错误情况，以备后续分析及查证。
7、在进行微信退款（使用宫论统一退款SDK）时，由于接口返回的信息较为复杂，有可能由于接口函数等原因导致各种错误。为确保退款流程的顺利进行，避免因错误导致整个进程中断，特别采用了TRY-catch机制来捕获和处理异常。一旦发生异常，系统会立即将详细的异常信息记录到日志中，以便于后续进行问题的追溯和分析。此外，还会将封装好的错误状态返回给前端页面，确保用户能够获取到明确的反馈信息并进行相应的处理。
8、新增了微信退款日志【payment_refund】，它通过xc_log_error_warn日志接口进行记录，详细记录了包括退款时间、退款渠道、设备指纹、退款人、退款UA、退款IP、退款单号以及支付单号在内的一系列信息，以确保日志的完整性和可追溯性。该日志在微信退款请求发起前即被记录，一旦退款操作失败，则会额外记录相关错误信息，以帮助分析问题。此机制与余额退款的日志记录方式一致，确保每次退款记录都能够溯源且可见，为后续追踪和问题排查提供了可靠的依据。
9、当微信余额的退款状态标记为完成时，无论具体情况如何（状态可能返回为：PROCESSING表示正在退款中，ABNORMAL表示退款异常且对方账户有问题，或者SUCCESS表示退款已成功），系统将通过xc_insert_sql('xc_refund', $refund)来生成并写入一条新的退款记录。这条退款记录的结构会继承之前已封装完成的退款信息记录。需要注意的是，只要状态标记为完成且符合退款条件，无论最终退款是否成功，系统都会在退款订单表中创建一条相应的记录。
10、在处理微信退款过程中，当发生退款时，我们会根据不同的退款状态对支付单据（即原支付订单表记录，而非退款订单表记录）进行状态回调处理。如果退款成功（SUCCESS），支付单据的状态将更新为【refund】；如果退款出现异常（ABNORMAL），状态将被设置为【fail_refund】；在退款处理中（PROCESSING），状态则变更为【wait_refund】。此外，如果在尝试过程中捕获到异常，也会将状态改为【fail_refund】。
11、退款订单状态拦截提示进行修改调整：首先，针对原支付订单处于wait_refund状态的情况，将原提示【退款失败：该订单正在退款中\n如果三天内未到账联系平台客服】修改为【退款失败：该订单正在处理中。如果长时间未成功，请联系客服帮助解决问题！】。其次，对于支付订单处于fail_refund状态的情况，将原提示【退款失败：(订单等待手动打款处理)】调整为【退款失败：(订单等待人工核实处理中)】。

2024年11月13日
1、退款数组已经完成封装，用于处理退款操作。当需要发起退款时，系统会根据以下参数组成refund数组：number字段表示退款订单编号，该编号由xc_is_number函数生成；payment字段存储原支付订单号；method字段表示退款金额的处理方式，通常默认为原支付订单的付款方式；time字段记录当前退款的时间；amount字段为退款金额，系统会验证此金额不得超过原支付金额；type字段指定退款的发起方式，仅支持四种固定方式；status字段表示退款状态，默认为1，即成功；shop_order-shop_type字段表示商品类型，该信息从支付订单中获取；meta字段为自定义字段，可以为空；reason字段用于记录退款原因，该原因通过变量传递。
2、在余额退款流程中，当系统成功完成余额退款并执行了xc_update_money_hook钩子后，这一流程就已顺利结束。接下来，系统将通过xc_insert_sql创建一条退款订单的数据库记录，这个记录的内容完全根据refund数组的结构信息来填充。尽管我们不会监测该插入操作是否成功，因为数据库插入失败的几率极低，即便偶然发生了插入失败的情况，也不会对退款动作本身造成影响，只是会导致缺少相应的退款记录。...
3、支付订单状态回调的优化处理：首先，在处理退款订单时，直接将退款订单号写入到退款订单编号中（通过 xc_is_number 确认退款金额）。这样一来，若需追踪退款记录，可以通过 refund_order 来索引退款表中的编号。其次，利用 return_content 记录本次退款的原因，直接读取【reason】变量即可，因为该变量是必定存在的。最后，meta 信息将记录退款的方式、时间等详细信息，确保所有相关数据都能被准确追踪和管理。
4、新增日志功能【payment_refund】。无论是哪种类型的退款，只要退款流程一旦启动，相关记录就会被写入该日志文件。日志格式为【支付订单：退款人：退款时间：退款金额：退款编号：退款方式：退款IP：退款UA：退款指纹】。此日志的主要目的是记录每次退款操作，以便在发生退款异常时，通过日志查找退款发起记录，方便进行溯源和问题排查。
5、payment_refund 日志的记录时间是在发起退款操作后，并在执行 xc_insert_sql 插入退款记录之后。对于插入是否成功，不进行判断处理。一旦 payment_refund 日志被写入，就意味着本次退款已处于完成状态。为了防止数据表记录出现问题，增加一个文本日志存档，以便于溯源管理。例如：当某人进行余额退款时，会在 xc_update_money_hook 余额更新完成后，将本次退款记录写入日志文件，然后再写入到数据表中。
6、在处理退款时，如果出现异常错误，将会记录到错误日志中，日志标识为【refund】。日志的格式为：[退款时间 - ' . date("Y-m-d H:i:s") . '] [退款渠道 - ' . payment['pay_select'] . '] [错误 - 接口返回内容不可识别] [退款单号：payment[pays_elect]][错误−接口返回内容不可识别][退款单号− ′ .payment['id'] . ']。通常，退款异常多发生在使用第三方支付平台时，如微信支付或支付宝付款。而通过平台余额进行的退款则会直接到账，无需额外处理。
7、refund日志具备完善的报警机制，能够根据支付服务商返回的状态自动触发警报。例如，当服务商的现金余额不足以支持退款操作时，系统会立即发出短信和邮件警报，提醒管理员及时检查账户的财务状况，以防止退款订单的积压和处理延误。此外，平台商户账户被冻结、余额不足或处于风控状态时，也会触发相应的警报机制，确保问题能够在第一时间得到解决，避免因内部问题导致退款流程中断。
8、余额退款流程已完成封装处理：整个流程如下所述。首先，基础拦截部分负责全面检测和验证：在这一步，我们确保所有传入参数的准确性，并确认退款请求符合相关条件，同时检查用户的操作权限，以防止任何非法提交和潜在的安全风险。这一阶段的拦截基于通用规则实现。接着，进入余额退款的具体流程：该流程开始于通过xc_update_money_hook触发的退款请求。如果在此过程中出现任何错误，系统将立即返回相应的错误提示以便及时调整和解决问题。一旦退款操作成功，则会通过payment_refund方法记录整个过程的日志，确保每一步操作都有迹可循。紧接着，系统通过xc_update_sql更新原支付的订单号，将其状态修改为“已退款”，并同步更新所有相关信息。最后，通过xc_insert_sql方法，将当前退款的详细信息记录至退款订单表中。这种结构化的记录不仅便于后续追踪和查询，同时也为数据恢复和审计提供了可靠。
9、退款成功回调钩子，使用之前设计的封装函数【xc_payment_refund_ok_hook】。该钩子通过【xc_redis_count】计数器精确记录了退款相关的多维度数据，包括：平台总的退款订单额，支付场景的退款统计如【淘货（tao）】和【余额充值（recharge_money）】，以及具体支付方式的退款数据【如现金（money）、微信支付（wxpay）和支付宝（alipay）】。这些计数器功能强大，支持按年、月、日进行溯源统计，便于后续的数据分析和决策。同时，该钩子还会触发【xc_notify_hook】消息通知系统，将退款状态以消息形式及时下发至退款人账户，确保信息沟通的时效性。此回调在每笔退款成功完成后均会自动触发，保障流程的稳定与透明。
10、退款订单流程规范化要求：宫论整个交易体系非常复杂，涵盖多种交易场景。如果操作不规范，可能会导致平台资金出现重大损失。因此，每一个场景的退款请求都需要审计并确保操作流程合法合规。特别是以下几种交易类型（C2C：买家和卖家交易，包括商户交易、淘货交易、鉴定订单、转账红包），在处理这些场景的退款时需要注意两点。1、如果交易额已到卖家账户，在发起退款操作前，必须核验卖家的资金是否充裕以支撑退款需求。如果资金不足，则必须拒绝退款操作，禁止任何形式的平台垫付。同时，在完成退款操作后（退款过程中也视为完成），要及时扣除卖家相应金额，避免造成平台资金漏洞和损失。2、如果交易额未到卖家账户，则在完成退款操作后，要立即关闭订单处理。需要注意，退款钩子不负责验证账户资金情况，因为场景过于复杂。在发起退款前，必须根据具体退款场景验证卖家资金状态，不符合要求则直接拒绝。在完成退款操作后，需要执行卖家资金结算处理，确保买家收到款项，卖家也完成相应扣款。保证双方账户的资金往来是双方的责任，而非由平台垫付。
11、在完成支付订单的退款操作后，会主动调用xc_unlock来释放锁，以确保之后的订单操作能够顺利进行。为了确保整个业务流程的一致性，任何涉及退款订单状态变更的事件，如果需要进行锁定操作，都将使用refund:订单编号的方式统一处理。在完成退款请求后，存在一种可能情况是第三方支付平台返回的状态是“退款中”。此时，如果不及时释放锁，将会阻碍后续的异步回调（无论退款是失败还是成功）对退款订单状态进行必要的修改和处理，从而影响整体订单处理流程的顺畅运行。

2024年11月12日
1、针对余额更新操作进行了钩子的优化处理。每次执行操作前，系统会创建一个Redis锁，锁名格式为【update_money_用户、金额、订单编号】，锁的有效期设置为30秒。这一机制旨在防止合并执行的重复请求导致相同余额的重复入账或扣款，避免异常发生。同时，在操作执行成功或发生错误时，会提前释放锁，以防止余额操作因锁持有超时而持续返回异常状态。在遇到已加锁的情况下，系统将返回错误提示【操作过快：账户余额已上锁保护】，以提醒用户稍后再试。
2、为确保余额精度的可靠性，当通过xc_update_money_hook进行余额更新时，系统会使用is_numeric函数检查amount变量是否为数字类型。如果amount不是数字或其值小于0，系统将返回错误提示【错误：金额不是数字，或小于0】。在金额验证通过后，系统会使用floatval函数将字符串转换为浮点数，以确保后续的数字计算（如增减操作）能够依赖于精确的数值。这一流程旨在确保所有涉及金额的操作都能以最大的精确度和可靠性进行，从而避免任何潜在的财务错误。
3、余额更新钩子现已添加对text变量的安全验证措施。首先，系统通过xc_is_html函数验证字符串中是否包含HTML或代码片段，若检测到不允许的字符，将直接返回【错误：余额更新原因包含非法字符串】，此拦截机制有效防止用户通过余额更新钩子提交恶意字符，从而保护系统的正常运行流程。与此同时，系统还会利用mb_strlen函数计算更新内容的长度，若字符超过300个，则被视为不合法，此时同样会拒绝执行并返回相应的错误提示信息。
4、如果余额完成更新，则会建立一个更新数组对象【update_data】，里面包含了（state：状态为refund退款。refund_amount：退款成功金额、refund_time：退款日期时间、return_content：退款原因、meta：自定义原字段部分），该数组会作为支付订单表更新的结构，修改原支付订单。主要是将付款订单标记成已退款、退款响应的参数也同步写入过去。这样余额更新完成以后，也完成了支付订单的处理
5、支付订单的meta字段不再以数组形式进行存储和展示，而是采用JSON格式来处理。在退款流程中，首先利用json_decode将meta字段转换为标准的数组结构，以便进行各种操作处理。在更新相关内容后，在执行支付订单的写入更新时，通过json_encode将当前的meta字段转换为JSON格式进行存储，以确保数据的一致性和完整性。此外，为了保证中文字符在转换过程中不会出现转义问题，使用了JSON_UNESCAPED_UNICODE选项进行编码处理，这样中文字符可以被正确显示并存储。
6、在处理统一退款订单钩子时，会构建一个名为【device：退款设备信息】的数组结构字段。这个字段通过多种方式收集退款请求的设备信息：首先，利用$_SERVER['REMOTE_ADDR']获取当前用户的IP地址；其次，通过$_SERVER['HTTP_USER_AGENT']获取当前用户的设备UA（用户代理信息）；同时，使用函数xc_is_fingerprint()来获取设备访客的唯一指纹参数。这些信息的收集旨在实现溯源操作，一旦退款过程中出现问题，可以利用这些数据进行详尽的场景溯源。宫论平台自带的IP解析库和指纹库，通过IP地址和设备指纹的结合，可以有效追踪到设备的具体来源。
7、退款订单表中的字段【meta】现在支持通过refund变量以数组形式传递。这个参数是可选的，如果没有传递，将会把$refund['meta']设置为空数组，以避免字段缺失导致后续执行写入出现异常。特别需要注意的是，无论是device字段还是meta字段，都是通过数组来进行操作和更新的。然而，在进行数据库写入时，必须使用json_encode方法将其转换为JSON格式。
8、$refund['method']（退款订单方式）字段通过支付订单中的pay_select字段获取。例如，如果支付订单是通过余额完成付款，那么退款方式就必须是余额。这种做法的目的是防止套现和洗钱风险，确保支付金额以原路退回的方式进行处理。只有在账户出现问题导致无法完成退款的情况下，才需要通过财务审核进行手动打款。因此，退款需要遵循原有的支付路径。
9、$refund['number']退款的单号通过xc_is_number来生成和获取，这个退款单号会同步更新到支付订单表记录中。这个单号具有唯一主键性质，无论杀死支付单号还是退款单号，都可以通过这个退款编号来索引查找订单数据。同时$refund['time']，会获取当前日期，用以记录退款发起的具体时间，确保每笔交易的时间节点都清晰可追溯。
10、refund['status'] 的退款状态默认设置为1，表示退款成功。当退款过程中出现异常或错误时，该状态会被更改为其他状态。refund[ status]的退款状态默认设置为1，表示退款成功。当退款过程中出现异常或错误时，该状态会被更改为其他状态。refund['user_id'] 表示退款发起人的身份，通过 xc_is_login 方法获取。除非是系统发起的退款，该值必须存在，以便于后续的溯源和处理。这一机制确保了每笔退款都有明确的责任归属。同时，新增的退款钩子中增加了一个拦截器，如果退款方式不是 system，则必须确保 user_id 不为空。若 user_id 为空，则退款请求将被拒绝，并返回错误信息：“退款失败：非法参数请求-02”。
11、refund退款订单数组会从payment支付订单数组中提取【shop_order：退款商品订单号、shop_type：退款商品的类型】。这样是为了避免，退款查询页面，查找商品信息的时候，需要请求支付订单的问题。退款表集成了商品信息，可以直接通过统一方法获取到商品详细数据。注：虚拟类的交易商品，是没有支付商品信息的，这个需要做好页面判断处理。

2024年11月11日
1、新的统一订单退款功能【xc_payment_refund_news_hook】通过使用refund数组来传递相关参数，并实现了在验证流程中的自动化处理，已实现整个插入表的结构封装。除了支持传递退款渠道、原支付订单号和退款原因外，还允许使用meta字段来传递一些额外的外部参数，比如退款管理员的备注。这个meta字段采用json结构，因此在处理这些数据时，需要进行json解析以便正确获取和使用信息。这样的设计使得系统在处理不同退款请求时具有更高的灵活性和扩展性。
2、退款数据表优化重构：为了防止在实际使用过程中将channels和method字段混淆，我们对数据库结构进行了优化。原先的退款渠道字段channels改为type，以更明确表示退款的发起方式。同时，将method字段的注释更新为【资金退回方式】，用于指明退款金额的具体流向，比如退回余额或通过微信支付宝返还。这样的调整有助于清晰地区分这两个概念，避免因字段设计上的歧义而导致误解或操作错误。
3、退款钩子新增了一个渠道强验证机制，当触发退款请求时，系统会首先检查$refund['type']的值是否属于支持的类型。如果检测到该值不符合预设的退款渠道类型，系统将直接响应错误信息【退款失败：退款渠道不合法】，并拒绝执行后续操作。目前已支持的退款方式包括admin、seller、buyer、system四种。未来，在订单鉴权完成后，我们还将对每种退款请求进行独立的验证步骤。此机制旨在确保只有符合条件的退款请求能够被受理，从而提高系统的安全性和稳定性。
4、在完成基础参数校验后，系统将通过调用 xc_query_payment($refund['id']) 方法发起支付订单的查询请求。此前我们是使用 wpdb 来手动构建查询语句，而新版系统则通过统一的支付订单查询方法进行请求。若该方法返回 false，则立即返回“支付订单不存在”的错误信息，并终止后续的处理流程。特别需要注意的是，在处理退款订单的过程中，获取支付订单时禁止使用任何形式的缓存处理。这一点非常关键，以避免因重复请求而导致的多次退款。
5、在获取支付订单数据后，会对支付订单的状态进行严格的验证，以避免重复执行退款操作。若订单状态为"refund"（已退款），则返回错误信息：“退款失败：该订单已发起过退款，退款金额为（' . $payment['refund_amount'] . ' 元）”。若状态为"wait_refund"（等待退款），则返回错误信息：“退款失败：该订单正在退款处理中，如三天内未到账，请联系平台客服。”若状态为"fail_refund"（退款失败），则返回：“退款失败：订单等待人工打款处理。”最后，如果订单状态不是"ok"，则返回：“退款失败：支付订单状态不允许发起退款。”
6、在处理退款订单时，系统会进行严格的金额核对，确保退款金额不超过实际支付金额。如果发现退款金额超出支付金额，将返回错误提示【退款失败：退款金额大于支付金额】。在金额验证的初步阶段，系统还会对传入的$refund['amount']参数进行仔细检查，以确认其为有效的数字，防止由于非法字符或其他异常输入而导致的审核漏洞，从而避免在退款过程中出现意外错误。
7、退款钩子通过调用 xc_is_login() 函数来获取当前用户的账户UID。当退款渠道类型为【refund['type']】是卖家时，即卖家主动发起退款，系统会验证支付订单中的【refund[ 'type']】是卖家时，即卖家主动发起退款，系统会验证支付订单中的【payment['seller']】与当前用户是否一致，若不一致则返回错误并提示退款失败：无权操作。类似地，当买家发起退款时，系统同样会验证申请退款者是否为最初的付款人。对于管理员发起的退款，系统会检查请求者是否具有超级管理员权限。这三种退款请求类型都依赖用户的身份验证，以防止非法提交行为。此外，特别需要注意的是，无论是买家还是卖家在发起退款前，都必须对支付商品状态进行严格验证，以避免意外情况的发生。
8、在后台支付订单配置页面新增了一个名为【xc_pay_retund_key】的退款秘钥参数令牌。当系统发起退款请求时，必须传递该秘钥令牌，并进行严格的秘钥验证。只有当验证通过且秘钥匹配时，系统才会执行退款操作。这一验证机制旨在强化退款过程的安全性，有效防止数据包伪造，避免发生非法退款事件。同时，为进一步加强安全性，未来可增加对IP的二次验证，以确保操作环境的安全可靠。
9、为了确保退款过程的安全，系统通过 xc_payment_refund_news_hook 发起退款请求，并引入安全锁进行拦截保护。在所有拦截检测完成后，系统会利用 xc_lock 进行锁定操作，该操作使用标识 refund_' . $refund['id']，并设置有效期为30秒。这样的锁定机制在退款过程中提供保护，防止并发导致的重复请求问题。如果获取锁定失败，系统将直接返回错误信息：“退款失败：重复请求（订单锁）”，确保每个退款请求的独立性和安全性。
10、整个退款拦截过程已经完成了全面的封装和处理，具体检测流程如下：首先，验证提交的参数是否合法合规，例如检查退款金额和退款理由的准确性与合理性。接着，进行退款渠道的验证，以确保退款发起具有正当性。不同的退款渠道会有其独特的验证逻辑，以确保操作符合法定条件。此外，还需检测相关支付订单是否符合退款标准，防止出现不当或欺诈性的退款行为。最后，系统增加了订单锁定保护措施，以避免由于并发操作等原因导致的重复提交问题。这一系列步骤确保了退款流程的安全性和高效性。
11、余额退款流程处理：首先，当用户通过余额（money）支付订单后，如果此次订单需要发起退款请求，将通过 xc_update_money_hook 钩子进行处理。在这一过程中，余额更新的相关参数设置包括：更新人，即支付用户的UID；余额更新来源被标识为 "refund"；订单标识符则是对应的支付订单号。此外，余额的更新状态将设置为 "add"，表明此次操作为余额的增加，因为退款需要将款项返回至用户的余额账户。退款的具体原因将通过 $refund['reason'] 进行记录和说明。若在退款操作中出现失败，将会返回相应的错误信息，并阻止后续退款请求的执行，以确保交易的安全性和可靠性。

2024年11月8日
1、为了优化corn_identify_close的超时检查方法，目前引入了is_redis_corn方法来判断任务是否正在执行。如果任务正在进行中，系统将跳过本次执行。这一改进有效防止了在某些异常情况下，导致同一鉴定订单被重复关闭的问题。特别需要注意的是，订单关闭操作往往涉及到退款等重要的财务处理，因此，确保不发生重复退款以避免平台资金损失是至关重要的。
2、在后台系统中新增了名为“xc_identify_corn_expert”的字段，用于设定专家鉴定超时退回的时间阈值，以分钟为单位。该字段默认设置为24小时（即1440分钟），表示当鉴定订单在此时间内仍未被处理，即未发起鉴定流程，平台将自动进行订单退回处理。届时，鉴定订单将被关闭，买家支付的款项会原路退回，并且平台将对未能及时处理订单的鉴定师施以相应的处罚措施。此项举措旨在避免长时间未处理的订单引发用户不满情绪，保障用户体验。我们建议将该鉴定超时时间设置为大于48小时，以确保平台和用户双方的利益得以更好地维护。
3、当系统触发鉴定超时任务时，它会通过wpdb发起一个SQL查询。查询针对的数据表是xc_identify，并使用prepare来准备语句，以防止SQL注入的风险。具体查询条件是，从鉴定订单表中筛选出所有status状态为1（即处于待鉴定状态）的订单，并且其发起鉴定的时间time超过后台配置的鉴定时间上限（由xc_identify_corn_expert定义的小时数）。查询结束后，所有符合条件的结果将被存储到results中，并通过ARRAY_A格式将结果返回为数组，确保后续处理工作的简便性和高效性。
4、为了进一步完善安全措施，在成功通过get_result获取待退款的鉴定列表后，将启动一个for循环用于处理每个鉴定订单。在foreach循环的执行过程中，我们对每个鉴定订单进行上锁处理，其上锁标识格式为“identify_close:鉴定订单主键”，锁定时间设置为5分钟。这种锁机制不会主动解除，而是在有效期结束后自动释放，以此防止订单被重复退款的情况出现，从而进一步保障操作的安全性、合规性和可靠性。注：如果出现拦截，则使用continue退出当前任务，执行下一个。
5、新增了一个名为xc_payment_refund_new_hook的新版本订单退款请求钩子。此钩子专门负责处理新版本中支付订单的退款请求。命名时特别加上了"new"后缀，这主要是因为此前的订单退款钩子在执行标准和方式上与当前的完全不适配。然而，旧的业务逻辑仍在运行，无法立即切换到新系统，因此需要一个过渡期来处理兼容问题。在此期间，新旧退款钩子将同时启用，以确保业务的平稳过渡，未来将逐步由新钩子全面替代旧钩子。
6、在使用 xc_payment_refund_new_hook 退款钩子时，需要传递一个名为【refund】的数组，其中至少应包含以下四个关键参数：首先是 channels，即退款渠道。这是一个必须严格准确传递的参数，因为不同的退款渠道，如卖家发起、买家发起、管理发起或系统发起，涉及到不同的处理逻辑，决定了退款的流程和审批环节。其次是 id，即原支付订单的主键，通过这个参数可以提取到相对应的支付记录，确保退款的正确性和可追溯性。此外，amount 参数代表退款金额，必须精确到小数点后两位，以确保财务的准确计算。最后是 reason，这是退款原因，无论是哪种类型的退款，这一参数都是必不可少的，它可以帮助追踪退款的背景和必要性，为后续的数据分析和服务改进提供支持。
7、新版订单退款钩子现已采用标准化的数组结构返回数据，这一改进旨在优化后续业务流程处理和错误日志记录的效率。具体的数组结构定义如下：code字段用于表示处理状态，其中0表示退款处理成功，1表示处理失败。msg字段则提供退款失败的具体原因和详细信息。在进行后续业务判断时，可以通过code状态标识来判断退款处理结果。需要特别注意的是，对于第三方支付的退款请求，如果系统返回“正在退款中”的状态，此时code依然会返回0，以表示退款处理尚在正常进程中。
8、在订单退款钩子执行过程中，有三个关键的基础拦截事件需要注意。一是通过is_numeric函数验证退款金额的合法性。如果退款金额不是有效的数字格式，则系统会返回错误提示【退款失败：金额不是有效数字】。二是对退款原因reason进行检查，确保其中不存在非法字符或HTML代码。如果检测到非法字符，系统即刻返回【退款失败：退款说明包含非法字符】的错误信息。而且，若退款理由为空，系统同样会返回错误提示。三是验证退款渠道channels是否合法，确保其属于支持的类型列表中。如果退款请求的渠道不在支持的范围内，系统将拒绝请求并返回【退款失败：非法请求！】。这些拦截事件的设计旨在提高系统的安全性和可靠性，确保退款过程的顺利进行。
9、封装一个新的订单编号生成方法【xc_is_number()】，专用于生成独特的字符编号，以便用作单据的主键。该方法确保生成的编号具有唯一性，具体生成过程如下：首先，获取当前系统的微秒级时间戳，以捕捉精确时间。随后，利用 uniqid 函数生成一个独一无二的ID，以确保唯一性。接着，生成一个介于1000到9999之间的随机整数，增加编号的随机性。然后，将时间戳、唯一ID以及随机数进行拼接，形成初步的编号字符串。在此基础上，移除不必要的字符（例如小数点），并通过哈希算法转化为32位长度的字符串，确保最终生成的编号具备唯一性且符合使用标准
10、xc_is_number 方法默认返回16位的字符串编号，为了避免写入生成过程中的失败，系统数据表在规划单据编号时，字段长度应大于16位。此方法新增了一个长度变量 length，用户可以通过该变量调整返回编号的位数。如需32位编号，只需将长度变量设置为32。系统会根据要求自动截断或重新组合编号，确保其独特性和符合性。请注意，该方法的返回编号长度最低为8位，最高为32位：若设置小于8，则返回8位；若超过32，则返回32位。
11、新订单退款发起钩子现已优化，全部依赖于refund数组来创建退款订单的详细信息。在初始化阶段，该数组会接收包括退款渠道（channels）、退款订单ID编号（payment）、退款金额（amount）以及退款原因（reason）等关键参数。如果存在退款发起人，将通过xc_is_login函数获取当前用户的唯一标识。同时，退款订单的编号会通过xc_is_number自动生成处理。其他相关参数则根据具体的订单退款方式进行填充，以确保每个退款请求的处理都准确无误地记录和跟踪。

2024年11月7日
1、在宫论定时计划函数库中，新增了一项重要任务：corn_identify_close，该任务专为系统自动执行设计，用户环境下调用此方法会直接返回false。目前，这项任务已被分配至后台的定时计划，每隔30分钟启动一次。其主要功能是检测系统中超出XX小时未完成鉴定的订单，并在必要时启动关闭订单的流程，同时执行相应的退款操作。此外，该任务在执行过程中还会触发预设的回调通知，以确保所有相关方都能及时获取信息更新，优化订单管理流程的效率和用户体验。
2、新增了宫论通用订单查询脚本库的方法：xc_query_refund。此方法的功能是，当你传递退款订单号或退款订单编号时，它将自动返回对应的退款订单数据表信息结构。在设计订单表时，有一个关键点需要特别留意：对于订单号的生成，不要使用传统的纯数字编号方式。推荐使用如random_bytes等方法来生成独特的字符串，以避免重复值的出现和可能带来的问题，尤其是订单号不建议使用数字形式处理，以确保系统的稳定性及数据的唯一性和安全性。
3、在xc_query_refund退款订单查询方法中，首先利用is_numeric函数检查传入的查询参数ID是否为数字。如果ID为数字，那么便通过主键ID进行查询，利用内置的原生方法xc_get_sql直接获取对应的订单表记录。在参数不是数字的情况下，则假定ID为字符串组合，即退款单据编号，此时借助内置的wpdb，通过构建一个原生查询方法，向数据库请求并返回匹配的订单数据记录。无论采用哪种查询方式，返回的数据始终以数组形式呈现。
4、在优化区分订单属于订单号还是订单主键的方法时，之前主要依赖is_numeric函数来检查传入参数是否为数字，这种方法不够严谨并且可能引发误判。因此，除了使用is_numeric验证外，还加入了通过strlen获取查询参数长度的判断逻辑。如果参数长度不超过8位，则判定为订单ID进行查询；如果长度超过8位，则判断为订单号。这种双重验证机制，有助于提高订单查询的准确性与可靠性，特别是在大规模数据处理场景下，能够有效减少错误查询的概率，确保系统在订单辨识上更加高效。
5、在xc_query_refund中增加了一个名为【uncache】的变量，默认值为false。通常情况下，退款订单的查询首先会检索Redis缓存，当缓存中没有结果时，才会通过内置方法从数据库中读取数据，并更新到缓存中。Redis缓存的键设计为："query_refund:" . $id，缓存的有效期设置为86400秒（即1天），在此期间缓存会自动失效并释放。如果将uncache参数设置为true，则查询不依赖缓存，直接从数据库读取数据。这种设计是基于退款订单数据的敏感性，因此对于缓存的控制需要格外注意，以确保数据的准确性和安全性。
6、退款订单查询方法已完整封装处理，具体的查询流程如下：首先，系统会检测所输入的订单号，判断其是主键还是单据编号。如果订单号为主键，则会通过 xc_get_sql 方法来获取查询结果。在执行此操作之前，系统会验证缓存功能是否启用。如果缓存功能尚未启用，则在调用 xc_get_sql 方法获取结果时，将第三个参数标记为false，以禁止缓存结果返回。而如果订单号不是主键，系统则会通过内置的 wpdb 构建单独的查询方法，向数据库请求返回数据。在发起这种查询之前，同样会检查此次请求是否支持缓存。如果支持，则优先从缓存中获取数据。无论选择哪种查询方式，只要获取到订单数据，系统一定会返回一个数据数组。如果查询没有任何结果，则返回false。无论是数据库没有结果，还是查询过程中出现错误，系统都统一返回false，且不会返回空数组。
7、新增了一个支付订单查询方法：xc_query_payment。此方法要求传递支付订单编号或支付单号的主键，能够智能识别参数类型并选择合适的查询方式。如果识别为主键，则通过ID进行查询处理；若识别为订单号，则使用【商户单号】在payment_order中进行检索。需要注意的是，商户订单号是平台自动生成的，无论是余额支付还是通过第三方支付，该订单号都会在订单生成时自动创建，其长度大约为18位。调用该查询方法后，返回值必定为一个数组结构；如果查询失败，则返回false。
8、xc_query_payment目前已新增支持缓存的查询返回功能，增加了一个名为uncache的变量以控制是否使用缓存结果。若该变量设为false，表示本次查询允许使用缓存返回，这样系统会优先尝试从缓存中获取数据，如果缓存中没有可用结果，才会通过wpdb进行数据库查询。默认情况下，uncache的值为true，意味着查询禁止使用缓存，以确保数据的实时性和准确性。尤其是在订单支付查询过程中，考虑到涉及安全问题，默认禁用缓存以防止因状态更新不及时而导致的错误回调事件。这点与其他查询接口有根本性差异，需要特别注意和说明。
9、支付订单查询缓存与其他订单查询缓存存在以下几个不同点。首先，支付订单查询缓存的键名格式为：query_payment:+查询ID参数，而且在支付订单发生状态变更时，需要立即清理对应的缓存结果，以确保数据的及时性和准确性。其次，在缓存时效上，正常订单查询缓存的有效期通常为86400秒（即1天），但由于支付订单的特殊性，其缓存有效期被严格控制在1小时。这意味着，超过1小时后，该缓存将自动过期并被删除，以防止旧数据影响支付处理。此外，支付订单查询禁用了xc_get_sql查询处理，要求无论是主键ID还是其他条件的查询，都必须通过wpdb查询来执行，以确保数据的完整性和系统的稳定性。
10、鉴于业务的复杂性，为了进一步加强系统稳定性，所有订单查询接口的xc_get_sql请求方法已被移除。这一调整旨在减少异步进程可能引发的故障风险，从而避免整个查询操作的崩溃。现在，无论是主键查询还是通过订单号进行查询，订单查询接口均已统一改用wpdb方法来构建并执行SQL查询。同时，缓存处理流程也进行了相应的调整，所有数据均通过wpdb返回并直接写入Redis缓存。这样的改动确保了数据处理流程的稳定性和可靠性，提升系统整体性能。
11、为了确保后续查询的统一性，并为未来的扩展和系统集成做好准备，订单查询方法采用标准化的函数设计方案。制定了明确的命名规则：格式为xc_query_【订单表名称】，例如，鉴定订单的查询函数命名为xc_query_identify，退款订单的查询函数则为xc_query_refund。这样设计使得通过表名即可直观识别对应的订单查询功能。为了确保缓存清理操作的一致性，函数的缓存键值也采用相同的命名策略。查询方法支持通过【id主键】和【order：订单号】进行查询，并且缓存的生效与否由变量uncache来控制，

2024年11月6日
1、退款订单表的结构字段设计完善，涵盖了退款过程中的各个关键环节。在这些字段中，id作为主键，用于唯一标识每一条退款记录；payment链接到支付订单表，保证追溯到原始支付信息；method和refund_channels则用来记录退款方式和渠道，帮助明确退款的途径。time和refund_time分别记录了退款的发起和成功时间，这有助于监控退款的处理时长；refund_amount和refund_order分别记录退款的具体金额和唯一订单编号，确保财务数据的准确性。status用于实时跟踪退款进展，而refund_fail提供了在退款不成功时的错误信息，有助于后续故障排除。user_id和device字段记录发起人及其使用的设备信息，能够在需要时进行用户行为分析。shop_order和shop_type提供了与退款商品相关的具体信息，进一步细化商品追踪。最后，meta字段则用于存储其他自定义退款信息，用于灵活扩展和满足更多业务需求。
2、退款订单字段的命名方式进行了优化调整：原有的“time”字段名称更改为“refund_time”，以明确表示该时间为退款发起的具体时刻。同时，将“退款到账时间”字段更名为“success_time”，这样可以更加清晰地传达字段的意思。此外，新增了“refund_data”字段，用于存储服务商提供的退款单据信息数据包，使得后续的溯源操作和处理变得更加便捷。
3、将退款成功的标识字段调整为【success_data】，退款失败的标识字段调整为【fail_data】。这两个字段目前都以text格式进行存储，其内容为JSON格式包。在未来MySQL系统版本升级后，这两个字段将直接升级为【JSON类型】。这个调整旨在优化退款异常问题的追溯和分析。在退款过程中，如果出现任何错误或异常情况，这两个字段将记录服务商返回的错误信息，以便进行溯源操作和跟踪整个退款流程的状态，从而提高问题解决的效率和准确性。
4、关于退款单据表的字段类型规划进行了详细的处理：首先，id作为主键，使用递增的数字，所以采用int(11)数据类型。payment字段获取的是原支付订单表的主键ID值，因此也选择int(11)存储。method字段代表退款方式，以字符标识来表示类型，所以使用VARCHAR(16)。refund_amount用于存储退款金额，使用标准的decimal(10,2)格式即可。refund_order是退款编号，因为生成的单据号可能较长，因此使用VARCHAR(32)进行存储。refund_channels当前采用数字区分操作对象，但为了后续的兼容性，决定使用VARCHAR(16)。status表示退款状态，用固定的单数字表示，使用int(2)。fail_data用于存储错误返回信息，采用text文本格式，未来可能升级为JSON。success_data同样用text存储成功的返回信息，后续也可升级为JSON。user_id是用户的UID，选择标准的int(11)。device存储设备信息，计划未来以JSON格式储存，因此目前采用text文本。success_time表示时间字段。shop_order和shop_type用于记录退款商品的关联信息，均使用VARCHAR(32)存储。最后，meta和data都是JSON存储类型，临时使用文本进行处理。
5、数据表字段规划要求：为了确保未来跨语言的兼容性，关联字典类型的存储内容必须一律采用JSON格式来存储和解析。尽管当前数据库版本尚不支持直接以JSON格式进行存储，因此现在暂时使用TEXT文本方式进行存储。然而，为了避免解析错误，在数据读取和写入过程中必须严格遵循JSON格式进行处理。需要注意的是，JSON不仅支持跨语言读取和解析，还允许针对字段设置索引。因此，要求将PHP的序列化数组字符形式进行更改，统一为JSON格式。
6、在对退款订单表字段命名进行进一步优化处理时，已经将冗余的前缀和后缀进行了清理。例如，将“退款时间refund_time”精简为“time”，“退款金额refund_amount”更改为“amount”。此外，对于存储成功或失败数据包的字段“success_data”和“fail_data”，也去除了“_data”后缀，只保留为“success”和“fail”。这种简化命名的方法有助于提高理解和解析的效率，确保字段名称既直观又不容易产生歧义。
7、将refund_order退款单据的字段名称调整为：refund_number。这是因为“order”是MySQL的保留字段，使用此字段可能导致一些兼容性问题，尤其是在读取数据记录时，需要使用反引号来避免歧义。为了实现更规范的处理，后续在新建表时，对涉及单据号、订单号等字段的处理，将禁止使用“order”字段，统一采用“number”进行命名。例如，payment_number、tao_number等。这样做不仅能提高系统的兼容性和维护性，还能减少因命名问题带来的潜在风险。
8、对退款订单表进行优化，增加两个新的字段。首先是“reason”字段，用于记录退款原因，无论是系统自动处理还是用户手动发起退款操作，都需要填写或选择相应的原因。该字段将以VARCHAR(500)格式存储文字信息。其次是增加“payment_amount”字段，用于保存原支付订单的金额，格式为decimal(10,2)。引入这一字段是因为某些场景下需要进行统计分析（如计算退款百分比），单独存储原支付金额后可以减少查询时的表连接，提高查询效率。
9、为了提高查询效率，与管理退款数据的复杂性，xc_refund增加了键位索引机制。具体来说，为以下单个字段建立了索引：refund_number（退款单据号），确保在查找特定退款记录时能够迅速定位；user_id（退款发起人），方便快速查找某个用户的所有退款记录；status（退款单据状态），便于快速筛选当前各状态的退款情况。此外，针对退款单据，创建了一个组合索引，这些字段包括：method（退款方式），时间维度上的TIME（退款时间），金额层面的amount（退款金额），以及多样化的channels（退款渠道）。该组合索引使得复杂查询能够更加高效，特别是在需要根据多个参数来筛选或分析退款数据时，大幅提升系统响应速度和数据处理能力。
10、宫论的统一退款订单表采用了高效的索引机制和缓存设计方案，具体包括多个关键部分。首先，在字段索引机制方面，系统支持对退款单号和退款状态进行单字段索引，同时还加入了基础退款参数信息的组合索引，以大幅提升查询性能。在查询缓存上，方案则支持基于ID主键和number编号的查询索引，并利用REDIS缓存技术进行处理。然而，由于退款订单涉及到关键的资金流向，为了防止缓存结果可能导致的异常判断，系统在进行退款订单状态的写入操作时，禁止使用缓存机制，以确保数据的实时性和准确性。
11、在后台日志报警配置中，新增了一个重要的【退款失败异常通知】场景。当支付服务商返回退款失败时，该场景将被触发。具体触发条件包括：用户或平台发起退款请求，且支付方式为微信或支付宝，要求进行原路退回。这时，通过接口发起的退款请求会先返回「正在退款中」，并将订单状态标记为退款中。如果异步接口接收到退款失败的消息，则触发日志报警机制，并通知相关部门进行处理。由于该通知场景的关键性，特别开通了短信通知提醒功能，以确保及时响应和解决问题。

2024年11月5日
1、宫论定时计划中心，新增主副锁定时计划【鉴定订单超时关闭检测】 锁的有效期为18000秒（即30分钟），每隔30分钟检测一次，系统中超时未鉴定的鉴定订单，然后发起订单关闭操作处理。避免鉴定订单因为长时间未处理，造成用户不便。注：该定时计划，主要是要处理好一点：订单退款操作。因为订单必定是完成支付后，才会生成鉴定订单。
2、新增退款订单表：xc_refund（订单退款记录），该表负责记录订单退款记录。因为退款涉及到平台资金安全，需要对退款做全程追踪（每个订单的退款记录，都必须溯源追踪到）。原来的旧表【wp_xc_pay_refund】无法满足需求，因为新的支付体系架构的存在，这次做退款流程操作的时候，干脆直接重构处理。确保统一支付架构和统一退款架构是相互相同，确保平台的资金的始终是可靠的。
3、退款订单表需要规划以下字段：首先是 id，这是退款订单的唯一标识。然后是 payment，用于存储支付单号的主键值，通过这个字段可以追踪相应的支付记录，请注意这里要明确是记录支付单号的ID，而不是指主键ID值。接下来是 method，表示退款方式，默认情况下退款会遵循原路返回原则。目前系统支持三种付款渠道，对应的退款渠道也是三种：余额退款（money），微信退款（wxpay），以及支付宝退款（alipay）。time 字段记录退款时间，格式为年-月-日 时:分:秒（Y-m-d H:i:s）。然后是交易金额字段，用于存储原始支付的金额。最后是 refund_amount，这是具体的退款金额，需与原支付金额保持同步更新，以便准确反映每次退款的金额变化。
4、退款表不仅保留了基础数据，还新增了以下字段以更有效地跟踪和管理退款进度。首先，refund_order字段用于存储退款订单号：在现金退款的情况下，该订单号是系统自动生成的；而在通过微信支付或支付宝进行退款时，则由支付平台服务商提供相应的订单号。其次，refund_data字段保存退款数据包；这个字段直接存储微信和支付宝返回的原始退款信息，以确保能够方便地进行溯源和后续处理。最后，refund_reason字段记录退款原因；无论退款是因为什么原因触发的，都必须详细描述，以确保能够明确退款的背景和原因，从而提高处理效率和透明度。
5、退款订单的原因多种多样，因此不同的退款方式拥有各自的验证与拦截机制。为了确保这些机制的可靠性，将会整合退款渠道的拦截逻辑。为此，退款订单表新增加了一些字段，以便追踪和记录退款的发起来源。其中，"退款渠道"（refund_channels）字段用于标识目前的三种退款授权类型：1）系统发起的退款，通常是由于订单超时关闭或者售后问题导致的自动退款。2）卖家主动发起退款，包括卖家主动取消订单成功或者同意退款时的场景。3）买家主动发起退款，通常出现在订单尚未发货或未进行鉴定等情况下，买家主动取消订单从而产生退款。
6、为提升维护效率和场景区分的清晰度，我定不再使用整数数字表示退款类型，而是采用英文单词进行说明。具体转换如下：系统退款为“system”，卖家退款为“seller”，买家退款为“buyer”。此外，在原有三个退款类型的基础上，我们增加了一种新的退款类型——管理员退款（“admin”），此类退款适用于某些特殊场景，允许后台超级管理员直接对订单进行退款操作。这种调整不仅使系统的解析和理解更加直观，也为后续的业务处理提供了更大的灵活性。
7、在退款表中新增一个状态字段【status】，用于记录不同的退款状态，具体数值分别为：1表示退款完成，2表示正在退款中，3表示退款失败。余额退款通常由平台直接处理，因此此类退款通常不会失败。然而，通过支付平台发起的退款则不然，因为这些退款是用原付款路径退还，其过程中可能出现各种不可抗力因素。例如，支付账户可能被封禁、停用或限制交易，或者银行账户被冻结、银行卡被限制收款等。这些问题可能导致退款出现异常，并且这种异常状态并非实时更新，通常需要等待若干分钟或数小时后才能获悉最终结果。鉴于支付渠道的退款可能会遇到状态2（正在处理中）或3（失败）的情况，因此增加状态字段以便标记和管理退款处理过程，并为后续的跟进追踪提供支持。
8、考虑到退款失败的情况，需要由官方财务部门进行后续跟进处理。此时，工作人员需要明确了解导致退款失败的具体原因，以确定是否需要进行手动打款操作。为此，新增了一个refund_fail字段，该字段以数组的形式记录相关信息，包括退款失败的时间、具体原因以及错误细节等。这些信息来自支付服务商平台的接口返回数据，并对其进行了统一的封装。在前端页面上，这些详尽的退款失败信息将清晰地展示给财务人员，以便他们能够更方便地进行后续的手动退款操作。
9、为了确保退款过程的稳定性和可靠性，退款表中设计了两个关键字段用于记录发起人的详细信息参数。首先是"user_id"，即退款人的用户ID。这一字段必须存在，以标识发起退款请求的用户在平台上的唯一标识（无论是管理员、卖家还是买家，只要不是系统发起退款）。若用户自行发起退款，但该字段缺失，则显示退款请求存在异常，此时系统将拦截并阻止该操作。其次是"Device"字段，用于记录退款设备的信息。该字段以数组形式存储多种设备参数，包括退款人使用的IP地址、用户代理信息及设备指纹等。这些信息便于后续的操作溯源和追踪，确保系统对退款流程的有效监控和管理。
10、在退款表中，新增了两个重要字段：首先是refund_time，即退款成功的时间。这个字段仅会在status为1时记录，表示退款操作已经成功完成。此外，新增的refund_manual字段用于记录手动退款处理的详细信息。当系统无法自动完成退款时，订单需经过官方财务的审核流程。如果审核通过，并允许进行手动退款，款项将被转至对方的余额。此字段将详细记录相关手动打款信息，包括打款人、打款金额、打款原因以及打款时间等关键参数。
11、为了更高效地处理订单，退款订单表中新增了两个关键字段：【shop_order：用于记录商品订单号或商品编号，以及支付商品的关联单据号；shop_type：标识商品类型，比如“tao”表示淘货商品、“identify”表示藏品鉴定。通过设置这两个字段，可以有效追溯退款单据的来源，同时还能通过内置方法快速获取交易商品的详细信息。这一改进提升了订单管理的透明度与操作便利性。】
12、在退款订单表中增加了一个名为【meta】的JSON字段，用于存储各种自定义参数信息，例如退款备注等。选择使用这个字段的原因是这些信息仅在特定场景下供特定用户查看，不需要为其建立索引。这一设计符合实际业务需求，因为退款订单的处理流程相当复杂，涉及多个参数的存储与调用，而通过【meta】字段，可以灵活地将这些信息集中存储，简化数据结构并提高数据的管理与访问效率。

2024年11月4日
1、修复了鉴定师身份访问鉴定师订单详情页时返回并跳转至403拦截的问题【你无权访问该页面:鉴定编号】。该错误是由于xc_query_identify在处理订单查询时未能正确识别鉴定师字段，仅对鉴定人进行了字段识别处理。现已修复此问题，系统能够正确识别并返回鉴定师的UID，以便拦截钩子能够准确判断访问请求的来源。
2、在宫论统一支付订单生成钩子add_payment_order_hook中，处理鉴定藏品订单时，我们增加了一个拦截验证机制。该机制会检查收款人和付款人是否为同一人。如果检测到两者为同一人，系统将返回code=1，并提示错误信息：“订单创建失败：鉴定申请人和鉴定师不能是同一个人。”需要注意的是，后续计划引入更严格的限制措施，例如通过UA指纹识别来进行处理。
3、在使用weui构建表单展示效果时，通用类名组件样式【.weui-panel.header_info】通过自定义类header_info进行了CSS样式的调整。具体的边框组件调整细节如下：元素的外边距设置为1.5视口宽度单位（vw），以确保在不同设备上具有一致的间距；元素的边框圆角设定为5像素，使得边角更加圆滑，提升视觉美感；强制设置元素的上外边距为3视口宽度单位，并使用!important优先级以覆盖其他可能的上外边距设置，确保布局的一致性；元素的边框样式为实线，边框颜色选用浅灰色（#f0f0f0），边框宽度为1像素，整体风格简约而不失优雅。
4、在鉴定订单详情页中，如果通过 xc_query_identify 方法未能成功获取当前鉴定订单的信息数组内容，系统将直接在页面上通过 xc_empty 输出错误提示信息：“抱歉，单据编号信息存在错误，请核对后再访问”。此举旨在防止由于变量缺失而导致页面生成过程中出现大量错误，从而确保页面的稳定性和用户体验。
5、在访问鉴定师订单详情页面时，系统会两次调用【xc_query_identify：获取鉴定订单的数组结构信息】方法。首先，在访问拦截钩子事件中，通过内置的拦截器判断用户是否有权限访问请求，此时会调用该方法获取鉴定订单信息。其次，在完成基础拦截后，页面再次调用该方法以获取鉴定信息，并将返回的内容呈现在页面上。这导致请求被重复执行，尽管有Redis缓存支持，但仍然存在冗余。因此，需要对该流程进行重构优化，以减少方法的重复执行。
6、在执行访问拦截钩子之前，系统会通过 xc_query_identify 方法获取并赋值鉴定订单数据到 identify 变量中。接着，访问拦截钩子将 identify 作为第二个参数进行拦截验证。此过程中，内部的拦截行为不再进行重复的订单数据读取。拦截钩子会进行相应的适配处理，直接在内部使用 identify 来完成访问鉴权操作。此外，增加了一个判断：如果 identify 是空数组，则直接返回 false，以确保系统的稳定性和安全性。
7、在鉴定订单表（xc_identify）中新增了一个字段：income（鉴定师订单收入），其数据类型为decimal(10,2)，例如28.32。当订单完成鉴定并结算收入后，实际收入金额将被写入该字段，并展示给用户查看。如果发生退款等情况，金额也会相应扣除。设置这个独立字段的目的是为了精准统计鉴定师的收入情况。未来可以通过鉴定单号按日、按月、按年获取鉴定师的实际总收入，从而进行统计分析。
8、由于鉴定支付记录并未直接写入到 xc_identify 数据表中，而是通过一个关联字段【payment】来关联支付订单。因此，在鉴定订单详情页中，需要单独使用 xc_get_sql('xc_pay', $identify['payment']) 方法来读取支付订单数据表，并将返回的结果赋值给 payment，以便在页面中展示付款信息。需要注意的是，为了避免错误，在请求读取支付订单时，会先检查 $identify['payment'] 字段是否存在，如果不存在，则跳过该处理步骤。
9、在藏品鉴定订单流程完成后（即鉴定师已出具鉴定报告），页面将展示【本次收入】一栏。此栏会调用并显示收入字段 income 的内容，仅对鉴定师可见，且仅在 income 字段不为空时才会显示。鉴定申请人无法看到该信息。需要注意的是，鉴定收费与实际收入之间存在差异，因为平台会收取一定比例的佣金，因此鉴定费并不等于鉴定收入，故需单独列出一个字段进行展示。
10、现在鉴定订单状态【status】共划分为五种状态：1、待鉴定（藏品已完成付款，等待鉴定师进行鉴定操作）。2、已完成（藏品的鉴定报告已生成，鉴定师完成了鉴定处理）。3、超时关闭（因为超过系统时间，未进行处理。鉴定订单被系统退回处理）4、已退回（鉴定信息存在问题，比如材料缺失，无法完成鉴定，鉴定师可以选择性退回。）5、已取消（鉴定师发起鉴定前，用户可以选择取消鉴定）。这五个状态目前已固定写入，将根据场景变化进行不同的状态处理。
11、在鉴定详情页中，关于【鉴定费用和订单收入】的展示逻辑进行了优化。首先，订单收入这一字段仅对鉴定师可见，并且只有在income字段有金额时才会显示。如果发生退款等情况，系统会及时清空income字段以确保信息准确。其次，鉴定费用字段的展示条件是订单处于完成鉴定或待鉴定状态，其他状态下该字段将被隐藏，以避免不必要的信息暴露。
12、在鉴定配置模块页面中，新增了一个名为 xc_identify_time_out 的字段，默认值设定为48小时。该字段用于设定鉴定订单的超时时间，超过48小时未完成鉴定的订单将自动触发关闭操作。此设置提供了灵活性，允许根据需要调整时间，但通常情况下，超时时间必须大于24小时，以避免设置过低导致不必要的订单关闭。订单关闭后将会引发退款流程。

2024年11月1日
1、宫论缩略图获取方式进行优化调整，之前是通过xc_thumbnail($type)方法来获取需要传递一个场景标识，这个场景标识的指向配置为后台xc_thumbnail_config字段，但是该字段需要强制指定了才能返回，对于未配置的场景则会出现返回异常，为了避免此类情况出现，type可以选择为空，如果为空的情况下则读取默认缩略图配置参数。
2、在宫论缩略图配置页面中，新增了一个名为xc_thumbnail_default的字段。这个字段用于设置默认的缩略图配置，当前暂定的参数为宽度560像素，高度自适应的缩略图样式规则。此配置与xc_thumbnail方法配合使用，以便在传递的缩略图配置参数不存在或未传递的情况下，自动应用这个默认的缩略图规则。这样可以确保在各种场景下都能正确读取和显示缩略图。
3、鉴定师订单服务端返回的时候，处理缩略图方式如下。1、读取数据表字段：collection，并使用json_decode将其转为数组。2、从collection读取image键值参数，并赋值到自定义变量image_list。3、最后从image_list中获取第一张图片，并在末尾加上xc_thumbnail('identify')缩略图规则样式。4、最后将获取到的图片作为缩略图，写入到返回参数字段中。完成图片的获取。
4、对鉴定师订单列表的分页函数接口返回数据的排序规则进行了调整。现在采用 ORDER BY id DESC 进行排序，这意味着结果将按 id 字段降序排列（即最大的在前）。这样一来，返回的结果始终是最新的订单在最前面，确保鉴定师能够优先看到自己的最新鉴定订单列表。
5、xc_identify数据表进行清理操作，彻底删除重构前的鉴定订单数据记录。因为字段结构的变化，在处理参数的时候经常会因为旧表返回字段缺失，导致出现页面报错的情况。旧的鉴定订单表可以通过xc_identify_bat获取并查看到，有存档处理。如果需要进行连表查询，也是可以直接支持的。
6、修复鉴定订单缩略图无法通过$collection['image']提取成功的的问题，返回的缩略图仅有规则（?imageMogr2/thumbnail/500x）没有图片有效地址。该错误是由于collection存储图片地址并非是采用数组结构来完成的，而是通过;进行多图隔开处理。因此在获取缩略图前，需要通过exolode对字段进行数组切割处理。
7、鉴定订单模版展示标题优化，会使用三元运算来处理title标签内容字段的输出，如果已完成鉴定，则鉴定表必定存在title：藏品名称（鉴定师亲自写的），那么会直接输出这个名称到模版列表中。如果未鉴定，则会显示【鉴定编号：671a3ab1b09f4】671a3ab1b09f4是该藏品待鉴定编号信息。
8、鉴定模版输出的时候，会通过xc_get_avatar获取鉴定申请人的信息，并在desc子类容器中显示【申请人： $avatar['nickname_type']】【申请时间：申请时间：' . $data['time'] . '】通过xc_get_avatar来读取申请人昵称是为了间接的刷新缓存。因为后续的详情页会需要获取用户更多资料信息，如果通过通过get_user_meta没法做到缓存更新处理。后续仍旧多一次查询。
9、在鉴定模版列表中，我们通过 switch 语句解析 $data['status'] 字段，以便根据不同的状态显示相应的文字和背景颜色。具体规则如下：当状态为1时，显示【待鉴定】，背景颜色为蓝色（#151bff）；状态为2时，显示【已完成】，背景颜色为粉色（#ff157c）；状态为3时，显示【已退回】，背景颜色为紫色（#d515ff）；状态为4时，显示【已取消】，背景颜色为绿色（#06bb1d）；状态为5时，显示【已关闭】，背景颜色为灰色（#1e201e）。如果状态不在上述范围内，则显示默认状态【其它】。通过这种方式，不同的状态不仅在文字上有所区分，还通过背景颜色进行视觉上的区别。
10、对xc_is_page_open访问拦截钩子进行了进一步优化。现在，该函数会在内部通过xc_is_login获取当前用户的UID，并将其赋值给user_id变量。同时，在鉴定订单详情页时，会通过$identify['user_id']和$identify['expert']来判断用户的访问权限。如果用户既不是鉴定师也不是鉴定人，访问拦截钩子将返回$result['open']=false，强制阻止用户的页面请求，并跳转到403页面。
11、修复了403.php页面无法继承xc_is_page_open钩子返回的自定义错误标题和正文内容的问题。具体来说，当xc_is_page_open触发内置拦截器时，页面应允许自定义输出标题和页面内容，以满足各种错误信息提示的需求。然而，403.php页面自带的错误提示信息每次都会主动覆盖自定义内容。为了解决这个问题，已在代码中增加了一个if判断处理：如果存在result数组，则直接将标题和正文切换为数组中的内容，从而实现自定义错误提示。
12、鉴定订单详情页identify_order_details在使用xc_query_identify方法获取到订单数据后，会通过xc_is_config方法来读取宫论通用分类配置，并传递当前藏品鉴定的key标识来获取具体的参数信息，并从中获取到藏品中文名称、然后将其写入到申请类目专栏中。同时当前鉴定状态，也会使用switch方式来解析status字段来处理，并使用边框将状态进行标记处理。确保不同的状态，显示不同的边框背景。

2024年10月31日
1、xc_menu_switch_hook 钩子本身并不会直接触发 AJAX 分页请求，而是通过模拟触发滚动监听器来实现下拉选项的加载。这样可以减少重复的分页请求封装，直接使用现有的分页接口参数即可。这种方式不仅简化了维护工作，还使得开发者只需专注于统一分页接口的处理和监听器的分页场景处理。需要注意的是，通过钩子传递的 page_name 用于处理场景识别。
2、在分类菜单点击钩子中，当用户切换菜单时，我们会进行简单的内容交互验证处理。首先，通过page_name获取模版组件类名template_infinite_page，以判断当前页面是否包含分页模块。如果分页模块不存在，则返回错误信息，提示非法请求。其次，我们会检查当前页面的加载动画是否正在执行中，如果是，则跳过此次处理，以避免重复请求。最后，我们会检查全局变量infinite_loading的状态，以防止意外执行。
3、通过钩子触发数据填充流程如下：首先，获取当前页面分页组件的列表对象，并将其赋值给page_list。接着，将页面滚动导航位置调整到顶部，以确保用户从头开始查看内容。然后，为当前选中的菜单添加选中样式，同时移除其他菜单的选中样式，以突出显示用户的选择。接下来，将组件的排序状态更新为传递的值，以便根据用户的需求进行排序。将组件的页码重置为0，以从第一页开始加载数据。清空page_list的内容，以确保新数据的正确加载。最后，通过触发trigger('infinite')来启动滚动动作，从而发起分页加载，确保用户能够连续浏览内容。
4、xc_menu_switch_hook 菜单切换数据钩子已完成封装处理。现在，该钩子能够与分页模块和监听器组件配合使用，实现数据的自动切换和填充。在数据切换过程中，页面的原有内容会被自动重置，页数也会自动归位。菜单切换完成后，还支持通过监听器进行 AJAX 分页加载数据的处理。
5、对infinite_paging_api的自动分页接口进行了优化。之前，offset变量用于计算分页数据的位置，计算公式为(page - 1) *page−1)∗number。然而，如果传入的page值不正确，可能导致offset为负数，从而导致分页查询接口返回失败。为了解决这个问题，我们在输出offset变量时，使用了max(0, $offset)方法，确保offset不会为负数。这样，即使计算结果小于0，也会被强制设置为0，以保证分页查询的稳定性。
6、修复了滚动下拉时分页接口返回错误的问题，该错误信息为【Uncaught TypeError: Unsupported operand types: string - int in】。问题的根源在于 infinite[page] 未能显示有效数字，而是返回了 NaN 值。这是由于分页监听器在获取旧页码数时，使用了不存在的 page 变量。正确的做法是使用 infinite['page'] 来获取页码。通过调整代码逻辑，确保分页变量的正确性，成功解决了该问题。
7、在鉴定订单详情页中，已彻底移除GET参数中的【ID】值，仅保留对number的识别和处理。任何传递ID的请求将直接返回错误，并拒绝页面访问。这是为了实现规范化处理，确保所有鉴定订单的操作仅通过鉴定编号（number）进行识别，而不再使用ID。这一调整是为了适配和修正系统的处理逻辑。后续的数据库请求操作也必须通过number来完成，以确保请求的准确性和一致性。此外，列表页跳转至详情页的功能也已支持通过number编号进行处理。
8、在鉴定订单详情页中，所有的ID参数请求已成功更改为：number。同时修复了执行访问拦截钩子 xc_is_page_open 的问题。此前，该钩子在访问页面时会返回【访问被拒绝，很抱歉你无权访问】的拦截提示。此错误是由于ID值被移除后，拦截器未能适配新版的number变量参数所致。目前，我们已更新拦截器中的变量参数，确保不会再发生错误拦截，并避免返回上述错误信息。
9、新增样式：template_order_list。该样式采用了灵活的display: flex布局，左侧为通用图片输出区域，支持自定义图片样式；中间部分用于展示基本信息；右侧则是状态栏的展示区域。整个容器组件的高度设置为16vw。容器的子类参数包括：image（图标头像），中间子类名为content，包含下属类名title（用于显示第一栏标题）和desc（备注信息栏）。status为状态栏，显示对应的状态内容。
10、对template_order_list容器样式进行了优化处理。首先，新增了padding以调整父级元素的内边距，上下内缩高度为3vw，左右宽度为2vw，以防止页面因容器撑开而导致错位变形。此外，status状态图标的字体大小调整为3.5vw，以适应不同的页面窗口。通过设置text-align为居中，使内容在容器中居中展示，并通过border-radius增加了圆角效果。padding设置为四周收缩1vw的距离，同时使用flex: 1来确保布局的灵活性和一致性。
11、在鉴定报告的分页组件中，自定义类名设置为：template_order_list。通过这个类名，鉴定师订单列表页的内容将以特定的模版风格进行展示。现有的模块组件均支持自定义类名的设置，因此如果有特定的样式需求，可以在组件的配置中进行自定义操作。这种灵活的设置方式允许动态地接管输出的风格样式，实现页面效果的切换功能。
12、修复并解决了在访问动态内容页时出现的【Warning: Undefined array key "wx_mp_login" in、Undefined array key 'type" in】错误。这些错误是由于PHP 8.X升级后语法不兼容引起的。解决方案是通过使用isset函数来判断属性值是否有效，如果属性不存在，则跳过常规的if判断处理。wx_mp_login是用于公众号自动登录场景的配置参数，而type是评论框判断来源时需要使用的参数。通过这种方式，确保了系统在处理这些参数时的稳定性和兼容性。

2024年10月30日
1、在藏品鉴定订单页面（identify_order_details）中，新增加了一个名为【media_info】的box容器，用于展示以下三个内容：首先是鉴赏图片列表信息，这里会显示已上传的缩略图，用户可以点击这些缩略图以查看对应的高清图片。接下来是鉴赏视频播放控件，前提是用户已经上传了视频内容，用户可以直接在页面上播放观看。最后是鉴赏文字描述部分，这部分内容只有在用户已有填写的情况下才会展示，该文本无法进行变更或修改，主要用于展示，以便于鉴定师或用户方便查阅。这样的设计旨在提升信息的直观及完整性，增强用户的操作体验。
2、在订单详情页的头部展示区域（header_info）中，新增了鉴定费用的展示功能。用户在提交鉴定时所支付的费用将清晰显示于鉴定详情页中，方便鉴定师和用户同时查看支付情况。需要注意的是，虽然这里展示的是用户实际支付的价格，但平台在结算给鉴定师时会扣除一定的佣金。因此，为了更好地为鉴定师提供信息，后续还将添加一个仅鉴定师可见的字段，即【本单收入】，以便他们查看扣除佣金后的实际收益。
3、分页接口【infinite_paging_api】目前已经实现能够正确返回数据并与前端完成响应对接。此前仅实现了请求查询的封装，并未将实际数据传递到前端进行响应处理。现在，该接口可以顺利返回数据包的响应，前端也能够正常接收这些数据。需要注意的是，返回的数据是通过xc_identify_expert_identify_order_list_consult方法生成的，后续需要对接收到的数据进行进一步解析和完善封装。
4、对于分页接口返回的前端数据包，进行了结构优化，现在返回标准化的JSON数据包结构，以提升前后端交互的效率和易读性。在这个结构中，"code"用于表示请求状态，其中1表示无数据返回或发生错误，0表示有数据返回。这样的设计使前端更易于判断数据请求的结果。"msg"字段则提供对应的提示信息，如“请求成功”或“发生错误”等，根据具体场景需求决定是否需要向用户展示提示信息。此外，JSON数据包中还包含一段"HTML"代码，该部分前端只需将其直接插入至页面相应的容器中，无需额外处理。前端根据"code"值来决定是否停止进一步的下拉加载交互，以确保用户体验的流畅性。
5、为了方便执行回调操作，返回的鉴定订单将增加一个ID值，即identify-鉴定编号。这个编号用于在需要对鉴定订单进行页面回调交互时，锁定对应的ID即可。例如，鉴定完成后，需要通过该ID变更状态名称；如果鉴定被退回，则需利用此ID将订单从待鉴定列表中移除。由于鉴定状态变化较多，增加一个标识符可以更方便地进行跟踪和处理。
6、鉴定交互流程规范化处理：当前采用id主键和number鉴定编号两个参数，在提交到完成的整个鉴定流程中，前端和后端均需做双向兼容处理。这一做法导致工作量大幅增加，并使得维护过程变得复杂。经过综合评估，决定彻底摒弃ID值，仅使用number鉴定编号进行交互识别。今后，前端页面的交互及后端的业务处理都将统一通过number鉴定编号来实现身份识别。这一变更将有效简化流程，降低维护难度，提高整体系统的效率。
7、鉴定列表模板的返回结构体应按以下方式展示：左侧部分展示用户提交的第一张鉴定图片，采用缩略图样式以确保清晰且节省空间。中央第一栏需显示藏品名称；若藏品尚未完成鉴定，则应标识为“xxx待鉴定，编号：88787”。紧接着的第二栏则显示申请人的名称“申请人：xxxx”，以便于识别对应的申请者。第三栏则明确记录申请的提交时间，确保信息的时效性与准确性。在结构体的右侧，应有明确的状态标识，以便于查看当前鉴定进度与状态。
8、在列表模板的更新中，使用switch语句来转换鉴定师的标识状态，以更清晰地显示每个状态：1代表“待鉴定”，2代表“已完成”，3代表“已退回”。为了提高视觉辨识度，这些不同状态将通过背景颜色框进行高亮标记，使用户能够快速识别当前项的状态。此外，每个区域都会增加对应的字段类名，用于准确锁定元素的位置。例如，状态容器将设置类名为“status”，而图片容器则使用类名“image”。这不仅提升了页面的可用性，也简化了后续的样式调整和功能扩展。
9、新增了一个名为 xc_menu_switch_hook() 的统一菜单切换钩子，该钩子需要传递三个变量。首先是 type，用于标识场景，这样可以通过场景标识来识别来源，从而执行相应的业务交互逻辑，这也是为了实现所有菜单切换动作的统一处理。其次是 sort，它是切换的状态标识。因为菜单之间的内容不对等，需要主动传递此状态以确保能正确识别和处理。最后是 this，它作为上下文对象，负责提取自定义属性，并执行相关的页面回调操作。这个钩子的设计旨在简化菜单切换过程，提高代码的模块化和可维护性。
10、统一菜单切换的钩子规范已标准化：type将用于传递页面标识，因为标识具有唯一性，这样可以省去重复命名的麻烦，并且在页面锁定上非常有效。在页面交互中，可以直接利用type值来判断页面位置。同时，对于菜单的点击事件，现在已经增加了访问监听机制。如果用户当前所在页面的标识与type不符，则被视为非法访问，系统将直接返回false。

2024年10月29日
1、在xc_query_identify方法中新增了一个名为“uncache”的变量字段，默认设置为false。当将其设置为true时，本次查询将拒绝使用缓存，强制通过数据库获取最新的有效数据，获取到的数据会更新已有的缓存。在某些特定场景中，数据的敏感性要求较高，通过拒绝缓存的方式确保返回的是真实可靠的信息。
2、在使用 xc_query_identify 查询鉴定订单时，如果将 uncache 设置为 true，且传递的订单号正好是主键ID值，那么在通过 xc_get_sql 发起查询请求时，将会增加一个第三个参数（false）。这一设置表明此次数据查询需要直接通过 wpdb 的原生方法获取数据，而不使用缓存结果，以确保查询结果的实时性和精确性。
3、优化了wpdb查询语句以防止注入风险。在使用wpdb构建查询语句时，通过prepare方法进行SQL查询，从而有效防止SQL注入。同时，将查询方式改为get_row，仅返回第一条记录，从而提升查询性能和效率。此外，表的前缀现在通过$wpdb->prefix动态获取，这使得在后期更新数据表时可以轻松进行一键切换操作。
4、已完成对 xc_query_identify 方法的封装，这一方法将用于未来所有订单类查询的封装处理。其执行逻辑如下：首先，检查给定的 ID 是否为数字。如果是数字，通过主键 ID 进行查询，使用封装的 xc_get_sql 方法来发起数据查询，该方法内置了缓存设计方案。如果缓存被关闭，相同的 xc_get_sql 请求也会被标记为不使用缓存的情况。若 ID 不是数字，则将其视作鉴定编号进行处理。为此，系统会构建一个缓存键名（形式为 query_identify:" . $id），并使用 get_redis_meta 方法检查 Redis 缓存中是否已存在对应的数据。如果缓存中有结果，则进一步判断其内容，如果结果为字符串 "false"，则直接返回标记为 false 的结果。对于其他情况，直接返回缓存中的数据。不存在缓存时，系统初始化数据库表名并添加 WordPress 前缀，准备生成 SQL 查询语句以通过鉴定编号查询数据库。查询操作会获取一行结果作为关联数组返回。若查询成功，结果会被缓存至 Redis 中，缓存有效期为一天。若查询失败，则会将结果记为 'false' 缓存至 Redis，防止后续重复查询。
5、function/query.php订单缓存查询脚本库现已集成至宫论核心库中。对于所有使用宫论的项目，这意味着可以直接调用该脚本库的文件和方法，而无需加载任何外部依赖。考虑到订单查询是一个非常关键的环节，后续操作会相当频繁，直接将其继承到核心库中将有效减少频繁引入的麻烦，提升系统性能与操作效率。
6、order_details（鉴定订单页面）基于全新的标准构建，标识命名通过动态化引入实现优化。page-content容器添加了xc_app子类，以明确页面属于APP移动端，从而支持标准组件的集成与监听功能。前端在进行页面交互监听时，可以结合页面标识和content使用，以精准定位和操作元素。此外，该页面还通过is_page方法判断最终页面的位置，提升了页面的响应能力和管理效率。
7、在xc_is_page_open访问拦截钩子处，新增了一项拦截机制。当用户请求访问identify_order_details页面时，将启动xc_query_identify方法检查鉴定订单号是否有对应记录。如果查询结果为不存在（即返回false），系统会立即激活拦截机制，将用户强制重定向至错误页面，并在页面上明显提示【鉴定订单号不存在】。此拦截在页面加载之前便已完成，以确保用户无法访问不存在的鉴定单据页面，从而提升系统的整体安全性与用户体验。
8、为确保鉴定订单列表页面的设计规范明确，使得鉴定师和用户在查看时不会出现功能模块重叠的状况，页面设计需考虑区分两者的不同操作权限。由于该页面既供鉴定师也供用户查看，因此需要根据订单的不同状态（如待鉴定、已鉴定、已退回、已取消）提供相应的操作选项。为此，当用户进入页面时，系统将生成两个变量以明确身份：一个对应鉴定师（expert），另一个则对应申请人（applicant）。如果来访者是鉴定师，则expert变量为true；如果来访者是申请人，则applicant变量为true。页面操作功能的构建将依据这两个变量的状态来判断权限，确保功能模块的操作体验清晰、界限分明，从而避免产生误操作和功能混淆的情况。
9、在订单详情页中新增了一个名为“apply_box”的页面容器，用于展示鉴定申请的基础信息。具体条目包括：鉴定编号（如xxxxxxx）、鉴定栏目（通过key参数鉴权后返回对应分类，如瓷器）、鉴定人（显示站内的昵称信息）、鉴定申请时间（格式为Y-m-d H:i:s）、鉴定状态（根据订单的status字段输出对应内容，例如状态1表示“等待鉴定”）。
10、对鉴定订单表（xc_identify）进行了索引优化处理。首先，将number（鉴品编号字段）设置为主键唯一值，并为其建立单独索引。这是因为许多后续查询都依赖于鉴定编号，为了提升性能，这一优化是十分必要的。其次，将price价格字段的数据类型从varchar(32)调整为decimal(10,2)，以便更准确地表示和处理金额，例如2.32元。最后，删除了原有分类索引中的number字段，因为该字段已升级为主键，组合索引已不再需要。
11、新增通用CSS样式规则【box_info】，该样式专用于页面头部容器内容的展示。此前，每次都需要单独编写样式，非常不便，而且这样会导致样式表逐渐变得庞大冗杂。因此，我们引入了一个固定类名，通过此类名统一管理样式。这一新样式将与WeUI组件配合使用，以提升样式美观度，主要用于展示单据和客户信息的基础内容。
12、鉴定订单状态包括以下几种：1. 待鉴定：鉴定订单已完成付款，当前正等待鉴定师进行评估。2. 已完成：鉴定师已对订单完成了鉴定工作。3. 已退回：由于某些原因，鉴定师将订单退回，需进一步处理。4. 已取消：用户在鉴定师开始鉴定前主动取消了申请。5. 鉴定关闭：由于超时、违规操作或其他原因，订单被系统或管理员强制关闭。请注意，状态3和4的订单都会触发退款流程，意味着鉴定订单的关闭，一个是由鉴定师操作关闭，另一个则是由用户操作关闭。

2024年10月28日
1、在infinite_loading页面监听器中新增了一个作用域变量：infinite_content。该变量用于定位到.page-content. + page_name + _content元素的位置，即页面page-content容器的内部。这一调整是因为许多自定义属性无法通过组件模块直接获取，因此在执行AJAX分页加载请求时，需要使用page-content选择器对页面属性进行调整。为了避免重复调用造成的性能浪费，此次优化提前将选择器结果存储在作用域变量中，实现更加高效的页面操作。
2、在xc_template_infinite_page_html模板组件方法中，新增了一个可选变量：meta数组字段，默认为空数组。该变量用于在特定场景下传递自定义属性。例如，在鉴定师订单列表页中，分页加载时需要传递鉴定师的对象UID；或者在查询已完成退款的支付订单时，需要提供status状态字段进行判断。这些需求都可以通过传递meta数组来实现处理。模板内部会解析meta数组，并将相关属性写入待生成的模板HTML中。
3、安全优化：目前，宫论模板组件中的所有字符串信息都会通过esc_attr方法进行转义处理，以有效防止非法字符或恶意脚本的注入，避免可能导致的恶意执行问题。注意，此优化措施适用于所有模板组件中自定义PHP变量的字符串输出，确保每一处都经过esc_attr进行安全处理，避免非法参数写入的情况出现。
4、在后台新版缩略图配置中，新增了一个场景功能，即藏品鉴定的图片缩略图配置（identify）。用户提交藏品进行鉴定时，上传的图片将默认通过缩略图样式进行呈现。只有当用户点击查看大图或使用灯箱浏览时，才会真正加载原图。这一设计有效地减少了不必要的流量消耗，并显著提升了页面的加载速度。缩略图的样式采用：?imageMogr2/thumbnail/300x。值得注意的是，这种缩略图配置将贯穿整个宫论项目，是实施不可或缺的一部分。
5、新增鉴定订单详情页面：module/xc_identify/order_details.php，页面唯一标识：xc_order_details。该页面是一个关键的功能模块，专用于展示鉴定订单的详细信息。默认情况下，此页面的访问权限仅开放给鉴定师和发起鉴定的用户。根据用户权限的不同，他们在查看页面时获得的信息和可操作的选项也会有所差异。鉴定订单具有多种状态，而每种状态下，不同的用户和鉴定师可以执行的操作选项也各不相同。这也使得页面的设计变得相对复杂，但其对于整体业务流程至关重要。
6、访问鉴定订单详情页时，需要通过GET方式传递两个参数变量：1、id，即鉴定订单数据表的主键id值；2、number，指鉴定编号。这两个变量参数用于识别当前用户访问的鉴定藏品订单的唯一标识。通常，只需根据实际情况传递其中之一即可。如果两个参数都为空，页面将返回错误提示。建议优先使用number来传递变量，以避免对外暴露id。
7、鉴定师订单详情页现在按照新标准构建。首先，页面标识采用动态变量进行传递，所有涉及页面操作的地方均通过page_name变量进行输出。其次，在核心库的脚本加载完成后，会立即加载页面访问事件拦截文件（ajax_page），使用内置方法过滤和屏蔽非法及恶意访问行为。最后，引入模板引擎文件，通过引擎生成和处理订单详情页的模板组件。
8、订单详情页集成【xc_is_page_open】访问拦截钩子，当用户访问订单页面的时候，会判断是否有权限进行访问。判断标准如下。通过id或者number来构建wpdb方法去获取鉴定订单表信息，同时使用xc_is_login获取当前用户ID。并与返回的结果进行进一步对比，如果当前用户不是指定鉴定师、不是发起鉴定用户。则视为无权访问。注：拦截钩子执行的时候需要主动传递id或者number，要不然无法获取到相应参数信息。
9、新增了一个名为 xc_get_identify() 的订单读取方法，该方法专门用于获取鉴定订单的信息。其参数需要传递一个变量ID，这个变量支持输入鉴定编码（number）或鉴定表主键ID，函数内部会利用正则表达式来判断ID的类型。借助 WPDB，该方法能够读取并提取鉴定师订单的详细信息。当信息读取成功时，该方法将返回一个包含相应数据的数组结构；如果读取失败，则返回 false。
10、xc_query_identify方法现已支持缓存设计方案，缓存的键值为：get_identify:（鉴定编号或主键）。该方法首先检查缓存中是否有记录，如果存在则直接返回结果，提高了查询效率和响应速度。如果缓存中没有记录，则通过wpdb查询获取相应记录，并在返回结果之前将其存储到Redis缓存中，缓存有效期为86400秒（1天）。需要注意的是，如果wpdb未能查询到结果，方法会返回false，并将此结果以字符串形式写入缓存。当读取缓存时，会首先判断返回结果是否为字符串'false'，如果是，则直接返回false。这种处理方式确保了Redis缓存的结果更为精准可靠。
11、宫论项目新增了脚本库【function/query.php】，此脚本专门负责管理和维护订单查询接口的封装。所有订单类型的查询接口按照统一的封装规则命名为：xc_query_订单类型。例如，淘货订单查询接口为：xc_query_tao，保真阁订单查询接口为：xc_query_bzg。传递的参数将根据不同订单类型进行确定。该脚本的核心目标是实现统一管理，提升后期维护的便利性。鉴于订单查询接口通常涉及复杂的缓存管理机制，实施统一管理显得尤为重要。
12、在xc_query_identify执行结果返回前，会首先进行权限验证。如果当前用户未通过xc_is_login验证登录，则直接返回false。若用户已登录，在读取缓存或从wpdb获取结果时，系统会核实用户身份是否为鉴定师或本人账号。如果以上条件均不满足，也会直接返回false。不过，如果用户是管理员，则会跳过这些拦截措施。通过这一验证机制，确保鉴定订单的返回结果仅对相关当事人可见，增强数据的安全性和隐私保护。

2024年10月27日
1、修复并解决了“我的鉴定列表”页面的下拉滚动监听问题。在鉴定师向下拖动页面时，现在能够正确检测页面距离底部的距离。如果该距离超过500像素，则会触发下拉的ajax事件，从服务器请求更多数据以填充页面。之前版本使用的是page_content容器来处理监听事件，而在新版中，改用了模板组件，因此需要调整监听器的位置。通过调整后，监听器能够在页面拖动过程中实时计算距离，确保能够正确触发下拉加载功能。
2、宫论分页数据接口统一化标准：默认页数设定为20，无论是首页还是后续的分页数据请求，皆默认返回20条数据。为了防止兼容性问题，现有的分页请求暂时不做调整，依旧按照原先的页数进行数据返回。然而，对于通过模版组件构建的分页请求和下拉数据，一律采用20条的新默认值。需要注意的是，传统的10条返回可能在后续的大屏和折叠屏处理时出现兼容性问题，可能导致无法触发下拉滚动监听。
3、优化了全局页面的下拉滚动监听事件。现在，在监听当前页面（模板组件）的自定义属性page（页数）时，如果发现该属性为0，将自动触发$('.page-content.' + page_name + '_content').trigger('infinite');事件，从而进行数据初始化请求。通过这种方式，即使在模板分页组件场景中未主动传递初始化数据，也能够在用户访问页面时自动完成数据的初始化装填。
4、分页模板组件现已支持【infinite_loading】全局对象的判断处理，该对象负责管理所有AJAX分页请求。对象键值为【infinite_loading[page_name]，其中page_name是页面的唯一标识】。当页面符合分页加载请求条件时，对应的键值为true，不符合分页加载请求时则为false。在实现无尽滚动监听时，需要通过判断infinite_loading对象是否符合AJAX请求，以防止无限加载情况的出现，从而避免性能开销的浪费。
5、为了确保首页内容准确展示，分页模板组件的初始化内容的时，首先会通过page_list.empty()方法清空页面原有内容，避免原来的页面内容与新加载的数据叠加。完成清空操作后，在调用trigger('infinite')方法模拟滚动下拉事件，实现页面数据的重新填充。修复了之前未进行内容清理而导致的数据加载错误，避免了新的分页数据被加载到原来默认错误提示的后面。
6、宫论统一分页接口现在已适配（infinite_paging_api）请求，当收到模版组件构建的分页请求，都将转发到这个接口进行处理。该接口需要传递infinite数组对象，必备的参数有【page：页码，表明当前是第几页、key：场景标识，唯一属性】。可选参数有很多，可以根据场景的需求来传参，比如【sort：请求分类、author_id：用户对象】等等。
7、模板分页接口文件现已调整为返回标准的 JSON 数组结构。由于分页场景多样且各自返回的错误不同，所以不适合采用传统方式来返回数据结构（例如，在无数据时直接返回 false）。这种情况下，前端无法有效处理错误码，因此采用数组结构来处理返回结果。具体而言，code=0 表示数据返回成功，html 已经封装好的前端内容字符串（前端可直接插入）；code=1 则表示无记录或有错误，msg 字段提供具体的错误信息。
8、考虑到前端解析存在困难，分页接口在返回数据时，即使没有记录或出现错误，也会包含一个HTML字段。这一字段会通过xc_empty进行转换处理。前端只需专注于对code值进行判断，即可接受结果，将分页接口返回的HTML字段直接插入到相应的容器中。这样既减少了前端的解析和处理负担，也使得后续对返回结果的管理和维护更加简便。
9、前端已完成分页组件模板的结果处理。在服务端完成数据请求后，前端会根据返回的code值执行相应的页面逻辑。首先，如果成功获取到分页数据，则会将生成的HTML内容通过append方法插入到页面底部，并将page变量递增1。接着，通过attr方法将当前页数设置为有效值，同时将infinite_loading[page_name]标记为false，以允许继续触发下拉滚动来加载更多数据。其次，如果未能获取到更多的分页数据（code=1），则会将错误信息通过append方法显示在页面底部，并将infinite_loading[page_name]标记为true，以阻止后续的分页滚动加载。
10、新增前端回调钩子：template_infinite_page_callback()。该钩子将继承模板分页组件中的infinite对象属性值，并在服务端成功返回JSON数据包后被触发，无论code状态如何，都会主动触发此事件。目前，该钩子主要执行两个操作：首先，它会关闭加载动画，以完成页面的交互动作；其次，通过empty方法移除list中可能出现的xc_empty错误提示。
11、为优化前端回调钩子的管理，新增了脚本文件（callback.js），唯一标识为（xc_callbac）。该脚本采用延迟加载的方式，在页面完全加载后执行。通过wp_enqueue_script方法，将其加载到宫论项目中，仅供移动APP端使用。值得注意的是，所有回调事件均被整合到此脚本中，以便后续的维护和更新更为便利。此前使用的HOOK脚本方案非常不便，因此进行了这一改进。
12、宫论服务端同样也新增一个回调动作脚本【function/callback.php】该脚本库负责宫论统一钩子的回调处理，命名规范：xc_钩子的名称_hook_callback（$result）在设计钩子的时候，如果需要对返回结果进行后续业务交互处理的时候，就集成一个回调动作脚本，在动作脚本中使用websocket+redis，来完成消息转发功能。注：回调动作，必须是已完成状态，并且不支持任何形式的结果返回监听。只是单纯的触发事件。最好采用异步来处理回调行为，避免阻塞钩子的业务进程。

2024年10月25日
1、在处理媒体文件的回调动作时，当鉴定订单成功建立后，系统会从identify数组中检查是否包含【image：图片列表、video_url：视频地址】等信息。如果存在这些数据，将调用xc_upload_media_ok方法，将相关的图片或视频上传记录更新至对应的鉴定表ID。这一过程确保相关的附件媒体信息与鉴定订单正确关联，防止被系统的计划任务误删或延迟处理。
2、针对xc_upload_media_ok钩子进行了优化，现在第二个变量不仅支持字符串形式的图片或视频地址（切割;），还能够处理数组结构的图片列表。这个方法通过is_array函数来检测变量类型。如果检测到变量不是数组，就会使用explode函数对字符串进行切割处理；如果检测到是数组，则直接跳过切割环节。这一调整有效提升了方法的灵活性和兼容性。
3、在鉴定师获取新订单通知时，系统出现了“Uncaught Error: Call to undefined function get_user_mea()”的错误信息。这个错误的根本原因在于“Undefined variable $id”，具体来说，是因为在通知数组中，当尝试下发消息时，需要提取鉴定订单ID，并获取相应的鉴定信息。然而，在通过xc_get_sql函数读取数据时，由于ID参数缺失，导致了一系列的异常回调错误。目前，所有相关问题已被逐一修复。
4、已修复并解决大量出现的【Warning: Trying to access array offset on value of type bool in 】报错，问题出现在517、527和536行。该错误是由于identify并不是一个数组，试图提取键值时返回异常。这一问题导致短信和邮件消息发送出现异常，而服务号和公众号未受影响。经过排查，发现异常源于xc_identify数据表返回的数据错误，现已完成修正和处理。
5、藏品鉴定助理的UID参数已从19更改为35，以避免鉴定藏品类型订单通知错误地由余额助理下发。正确的服务号消息应由UID 35，即鉴定助理来处理。在创建鉴定师服务号消息通知时，由于疏忽忘记修改这个参数，导致所有鉴定订单的站内信和服务号消息都错误地由余额助理进行处理。
6、今天解决了在通过服务号消息访问订单列表时出现的致命错误问题。该错误具体表现为“Undefined array key 'author_id'”和“Uncaught ArgumentCountError: Too few arguments to”的报错。这一问题源于xc_is_page_open函数在访问拦截时需要传递author_id参数，而用户查看自己的订单时通常不会传递这个参数。为此，采用了三元运算符来处理参数可能为空的情况，从而成功避免了报错现象。
7、在修复访问鉴定师订单列表页面时，发现通过xc_identify_expert_identify_order_list_consult接口返回结果为空，并且出现了致命异常。经过排查，问题出在缺少对author_id的传递。该方法需要两个关键变量：author_id和$status，然而页面中并未主动传递author_id，这导致数据读取失败并引发相关错误。为解决此问题，需要确保在接口调用前，页面正确传递所需的author_id（鉴定师访问，这个值应该是user_id）。
8、修复并解决了【鉴定师订单列表】页面返回的错误问题，包括“Undefined variable $list_consult in”和“Undefined array key 'author_id' in”。由于新版接口已无需通过内置方法主动发起初始数据的加载，因此原来的list_consult数组对象已被移除。新版方法可以自动读取组件数据，从而顺利完成订单初始化的加载，实现了更高效的数据处理流程。
9、在开发分页滚动加载模板组件时，通过使用模板引擎生成该组件，以往流程中author_id（操作对象UID）是通过配置文件设定和提取的。然而，在实际的业务操作中，该变量应通过页面的GET请求参数来获取。如果继续采用固定值提取，可能会导致页面数据加载异常。因此，为了避免错误返回，我们决定取消这一属性的固定配置方式，使其更加灵活地通过页面传参进行动态获取。
10、分页加载组件的初始页数从1调整为0。之前由于初始页数设置为1，自动监听器会误认为页面已有内容输出，从而不会自动触发内置的ajax分页请求接口向服务端发送数据初始化请求。这一数值设置错误直接导致用户在访问订单列表页面时，无法看到相应的订单数据列表，页面显示为空白。
11、前端新增了一个名为is判断方法的xc_is_now_page()，该方法用于返回用户当前所在页面的标识。如果同时打开了多个页面，该方法只会识别出用户当前所处的最后一个页面。方法的判断逻辑如下：首先检索页面元素 page-content.xc_app，并通过last来获取最后一个页面。如果成功获取到相关元素，则直接返回该页面的标识名称（可通过page_name自定义属性来获取）。如果未能成功获取，则返回false。需要注意的是，该方法非常可靠且有效，当需要检测用户所在页面时，基本可以得到准确结果。但需特别留意的是，该方法仅支持新版页面，应避免因不支持旧版页面而错误地返回false。
12、宫论APP端页面路由访问机制新增了方法 xc_page_visit()，用于发起移动端页面访问请求。此前，大多数请求都是通过 xc_mobile_url(link) 方法处理，该方法仅支持通过JavaScript直接访问URL，并仅限于APP内嵌页面，适用于传统页面的跳转。然而，这样的方式无法满足现代页面访问的多样化需求。为了应对这些需求，新的页面访问请求方法需要支持多种操作，包括页面正常向下跳转、页面向上后退访问、刷新当前页面以及在当前页面加载新的内容。因此，我们特地设计了这个新的页面请求方法，以拓展现有功能，提供更灵活的页面访问机制。