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，如果超过三天未到账，请联系平台客服进行处理。】

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出