小小乐

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

测试看看最低多少钱？

内容测试出

2025年1月19日
1、xc_review_add_hook审核事件触发后，会生成redis缓存键值：review_list：$user_id。并通过get_redis_meta方法去读取这个缓存参数，如果获取成功则会说明用户存在待审核的记录，如果获取失败则说明用户没有待审核记录，此时会初始化一个变量【review_list】将其标记为空数组。注：如果redis缓存存在结果，也会直接返回结果到review_list这个变量。因为后续的处理是需要围绕着这个参数进行。
2、review_list参数是存储用户未处理的审核列表，因为审核类型有多种，因此需要采用数组结构来处理。但是为了跨平台的兼容性，这里必须存储采用的是json结构来进行。因此在读取到redis缓存结果的时候，需要对其进行进行数组转换处理，避免返回的结构因为是json无法进行数组操作。需要注意的是，在进行参数更新后，需要将其转为json，在执行缓存更新动作。
3、审核事件的触发执行流程如下：通过传递的user_id来构建一个专属的 Redis 键，然后尝试从 Redis 获取对应的数据，若为空，初始化为空数组。然后将获取到结果进行json转换处理，确保得到的数组结构。最后更新指定【KEY】审核待处理的计数，在原有基础上进行+1的处理，如果没有则设定为1。最后将数据回写 Redis，设置一年过期时间。
4、为了确保计数器的真实可靠性，除了通过redis缓存进行计数外，还会将其写入到用户的自定义元字段中。因为缓存并不是持久化的，可能会因为清楚缓存导致数据异常现象。因此还是要回传到数据库，这样即便缓存消失，其数据内容还是存在的。这里需要注意的一点是，其存储的结构和类型和之前保持一致，都是以json结构处理。非必要的情况下不要以反序号方式去存储。
5、处理计数器优化处理，因为多了持久化存储方案，因此存储流程发生了变化。首先会从 Redis 获取数据，若 Redis 中无数据，则尝试从用户元数据中获取。如果用户元数据中仍然没有结果，则初始化为空数组，如果Redis 中有数据，则直接解码。然后计数方式和之前一样，只是在末尾的时候，追加一个一个处理。更新用户元字段。确保最新的记录更新到meta中
6、xc_review_add_hook增加一个上锁保护处理，通过xc_lock进行上锁保护，锁的命名和之前的redis_key保持一致，保护期为30秒。如果取锁失败则代表有进程正在执行，此时会主动返回false，防止同一个请求被触发多次，造成计数器出现错误的叠加。注：涉及到参数写入的地方，最好对请求施加上锁保护，防止重复请求。前端发起的拦截并不可靠。
7、审核事件触发钩子处理，直接通过xc_notify_hook事件来执行即可，因为无论什么审核场景，都会触发消息通知【review】这个事件，因此可以将通知事件当做钩子触发场景，避免每个事件都去预埋钩子。不过需要注意一点的是，需要避免xc_review_add_hook阻塞消息通知的下发的处理，尽量不要在里面设计复杂的业务逻辑。而且xc_review_add_hook不能支持异步动作，因为通知本身就是异步动作，在进行异步处理会产生不可预控的错误。
8、封装一个全新的方法（xc_is_review_list）来获取待处理的审核任务数量，该方法需要传递固定两个变量值【user_id、key】内部会优先通过redis返回对应的审核类型的任务数，如果redis不存在结果的时候，将会通过用户自定义元字段【review_list】来处理。如果两者都获取不到的情况下，则会直接返回fasle（可以理解为0）。通过这样的处理，可以获取到指定用户，指定审核有多少没有进行审核处理。
9、xc_is_review_list方法除了user_id、key两个固定变量外，还增加一个可选变量count，该值默认为false。可以将其设置为true则会返回所有任务的总数。内部会遍历review_list数组结构，将所有的数量进行汇总，并进行统计然后返回。比如A任务有10条、B任务有3条、C任务有2条。那么会直接返回15的数量。相当于统计所有待处理的审核总数。
10、审核大厅页面【review_list】现在会使用xc_is_review_list方法来获取当前用户待处理的任务数，该方法会优先读取缓存，如果缓存未命中的情况下才会读取用户的元字段。审核大厅是展示所有的待处理的审核任务，因此是在循环遍历数组中执行处理。如果存在待处理的任务，会在审核菜单右侧增加一个status_mark标签提示，并通过红点方式正确输出实际的任务数量。
11、审核大厅页面结构重构处理，该页面是很早之前就规划的，后面标准的宫论页面做出了调整处理，因此页面结构需要同步处理，确保新版本的请求事件能够适应下来。调整的范围包括（1、集成ajax_page访问拦截事件，确保页面的请求是可靠的。拦截非法行为。2、page_name变量以前处理，整个页面明明都以变量形式写入，而非固定输出。3、正文区域增加类：xc_app，确保页面属于APP类型，支持页面锁定。4、增加自定义页面属性page_name）

2025年1月17日
1、在执行完成所有的验证处理后，寄售回收钩子xc_consignment_apply_hook会返回code=0、msg=‘寄售订单已成功提交’。整个的处理流程基本就已经追加完毕，后续如果需要对拦截或者回调做出修改调整，可以通过动态注册事件处理，也可以通过hook_afte和hook_afte两个钩子来进行。具体的话根据业务来进行设定，一般系统的行为通过自带钩子处理，外部事件则通过动态注册方法进行比较好。
2、前端新增回调动作事件：xc_hook_consignment_apply_ok，当服务端返回处理结果的时候。如果返回的收code=0，则表明申请已经成功提交，那么将会触发这个前端回调事件，负责页面的一些交互动作的处理。如果返回的是code=1，则页面会通过xc_msg触发一条短消息提醒，告知用户申请提交失败的具体原因。部分会携带jump参数，将会实现页面自动跳转处理。比如进入认证页面、进入绑定手机页面。
3、为了方便前端进行页面响应处理，寄售回收钩子如果返回的是code=0，还会额外返回两个字段参数。1、consignment：后端已成功封装好的订单数组对象信息，前端可以提取对应的参数，进行页面的参数处理。2、id：数据表主键ID值，这个参数相当重要，一旦提交成功，可以通过这个参数直接跳转到申请订单详情页。后续会进行集成处理。
4、防止非法触发页面回调动作，负责回调的动作钩子现在回初始化page_content变量，使用let进行区域锁定范围，避免溢出到外部造成内存泄露风险。封装的变量锁定元素位置publish_consignment_content，如果页面没有这个元素则说明用户并未处于寄售回收订单申请页面。此时会通过xc_is_last_page进行进一步检测，如果返回结果不等于publish_consignment则返回false。阻止后续的所有提交请求。
5、目前的页面回调交互设计规划比较简单，就是通过xc_setting_btn.xc_hook_consignment_apply进行操作按钮锁定，然后将其onclick事件进行移除处理，避免用户二次提交请求。然后将操作按钮文字变更为：寄售回收订单已提交成功。最后将背景颜色变更为更鲜艳的橙红色，提示用户此次操作已完成。注：通过xc_hook_consignment_apply进行元素锁定是为了兼容寄售和回收两个订单按钮。
6、修复寄售回收申请页面，联系人信息输入表单出现错误【 Trying to access array offset on value of type bool in 】该错误是集成了redis缓存方案后，但是没有经过验证直接使用，导致直接返回上述的异常报错结果，正确的处理方案为：使用三元运算进行empty进行验证，如果为空不存在则说明用户没有设置过联系人信息或者缓存过期了，此时应该将其设定为默认为空。
7、人工审核大厅（review_list），现在已经支持了寄售和回收的订单处理，当线上工作人员或者合作专家收到了用户的寄售或者回收藏品的申请订单，会在这个页面展示记录。需要注意的是：寄售和回收属于两个订单类型，她们并不归档在一起的。另外这个页面只是展示一个列表入口，需要点击进入对应的审核类型，才能看到完整的订单列表信息参数。
8、寄售回收订单比较特殊，获取待处理的任务的时候不能直接读取后台预设的sql参数，因为有个动态参数信息。user_id：这个根据当前用户ID来验证的。因为不同的藏品分类，设定的账户UID不同。因此需要做特殊处理。具体的方法为，读取后台的审核列表参数信息，如果key快即类别为【consignment：寄售藏品审核申请、recycle：回收藏品审核申请】，则单独执行sql的封装处理部分，不采用之前预设的值。
9、寄售回收待审核的数量，是通过total_count进行统计输出的。这个参数值的获取方式目前是通过下面sql语句来获取【SELECT COUNT(*) FROM wp_xc_consignment WHERE status = 0 AND type = 'consignment' AND auditor = $user_id"】其中status=0代表未审核的订单，type是交易的类型，如果是回收则变更为recycle，auditor则是当前用户，属于对方审核计划值。
10、考虑到审核场景的复杂性，后期会有各种各样的审核计划出现，如果每种待审核计划都通过sql语句去获取去待处理订单数、已完成订单数。那么后续的sql维护会非常的凌乱，而且稍有不慎就可能要对源代码进行重新变更处理。基于此，新增一个HOOK钩子。xc_review_add_hook（审核计划新增事件），不管什么样的审核计划出发，这个钩子都会触发并执行。然后在业务中进行一个订单计数，有什么需要扩展都几种在这里面处理，所需要做的就是，出现审核计划，确保该方法被触发即可。
11、新增的审核计划钩子事件，需要主动传递两个变量。1、key：审核场景配置标识，也可以理解为任务类别。2、user_id：触发审核的用户ID参数值。该钩子会返回标准的数组结构，方便后续的处理。如果执行成功则未code=0、如果执行失败则返回code=1。正常情况下不需要监听其返回结果，但是考虑到未来需求还是集成下，目前返回错误的可能只有一种，即传递的key未找到审核配置参数。

2025年1月16日
1、新增寄售回收申请成功回调动作钩子：xc_consignment_apply_hook_afte()，当用户提交的寄售回收申请，完成了所有的业务处理（系统数据表已成功，系统通知下发完成、媒体回调完成、缓存机制已生成）将会主动触发这个回调动作钩子，该钩子和之前设计的hook_before基本一致，主要负责后续的第三方业务回调使用。
2、寄售回收回调动作钩子，需要主动传递两个参数过去。1、consignment：用户提交的寄售申请数据表信息，这里面包含了所有参数信息结构，如果需要对原有的参数进行读取，可以直接读取consignment内容即可。2、Insert_id：这个参数是寄售回收订单表的主键ID，正常情况下，触发回调动作，必定是写入了数据表记录。两个参数可以根据情况来写
3、一旦触发寄售回收的动作回调事件，会首先读取Insert_id（寄售回收表的主键ID），然后使用之前已经封装好的xc_query_consignment方法来读取申请订单数组信息，并将结果保存到consignment_data数组结构中。后续的业务处理都将通过这个数组来进行解析处理，需要什么参数到里面进行提取即可。注：部分参数是以json方式进行存储的，因此需要操作需要进行解析处理。
4、使用回调动作钩子规范说明：里面的方法实现尽量采用异步处理方案，不要同步执行事件，避免阻塞进程 导致整个请求响应延后，造成前端用户体验很糟糕。其次关键一点，禁止返回任何结果处理，任何方法实现的hook_afte都严谨返回结果过去。这个钩子的定义仅是回调下发，不能接管主进程的处理。一般两个场景会用到。1、需要异步执行的行为，集合在这里执行。2、第三方事件的处理，通知它们订单处理成功了，自行处理下一步动作。
5、回调动作事件现在会动态注册（宫论动态钩子），具体操作为：在hook_afte事件的尾部挂载动作行为，xc_do_action(__FUNCTION__, $result, func_get_args());这个方法是以前封装好的动作钩子，能够实现外部事件的注册处理。示例：当寄售回收订单申请成功提交后，会触发hook_afte，执行完成基础的异步动作处理外，在触发最关键的【xc_do_action】，第三方外部扩展事件，将也收到对应的消息。
6、hook_afte触发的动态钩子，会主动传递两个参数过去。1、consignment：通过统一订单查询到的申请订单数组结构信息，可以在外部事件中直接使用。2、func_get_args这个默认读取当前函数传递的变量参数，一般为：insert_id。外部的注册方法为：add_action('xc_test_callback', 'xc_test_custom', 10, 2);来挂载函数，可以根据需要同时挂在多个回调钩子。
7、一旦通过add_action进行了外部注册后，就可以在不修改核心代码和函数的基础上，直接使用外部方法接管到寄售回收订单申请成功的通知。回调动作函数的命名方式是在原有函数名称后面加上"_callback"。例如，如果原函数是"xc_test()"，那么回调函数就是"xc_test_callback()"。注：当通过add_action注册回调函数时，需要注意参数的数量。如果原函数有3个参数，那么注册回调函数时，参数的数量就应该是4。
8、xc_do_action方法进行重构优化处理，第三个变量args选择变成可选范围。正常情况下可以选择不传递，默认只传递result需要返回的结果数组结构信息即可。经过这样的处理，通过add_action进行外部注册的时候，其变量参数值则固定为1。这里也算规范化处理，非必要的情况下，注册外部动作钩子仅支持result的处理，如果需要传递其它变量，则主动封装进去就可以。因为本身就是数组结构，是支持这样的操作处理的。
9、基于异步处理的支持，现在xc_notify_hook通知事件、xc_upload_media_ok媒体资源关联处理、update_redis_meta联系人缓存更新动作，都异步到xc_consignment_apply_hook_afte方法处理。这些事件都将采用异步进行处理，不在主进程中执行。尽可能的提升前端的响应速度，减少用户的等待响应时间。
10、至此，hook_afte已经支持了寄售回收申请的处理，既支持异步事件的下发，也支持外部方法的注册的处理。有效的提升了整体的执行效率，并让外部扩展接收响应结果的方法变得很简单。后续所有的钩子都将采用这一套方案来处理，这样整个宫论平台将具备更高的扩展性，几乎所有的行为都能够被外部接管（在不修改核心源代码的基础上，允许进行接管动作）这个接管是包括两个动作。1、执行前拦截处理，新功能增加，注册方法进行拦截处理。如果新增条件不符合要求，则仍阻止用户提交。2、执行后结果通知，新增的业务逻辑处理。可以通过注册方法接管处理结果，确保后续的执行都能够处理好。
11、xc_consignment_apply_hook：寄售回收申请钩子已完全封装好，整个钩子主要有三个处理环节。1、xc_consignment_apply_hook_before：全面的拦截动作处理，对请求做出全方面的核验，确保请求属于安全可靠的。并支持外部注册拦截方式。2、业务执行的处理部分：完成请求核验操作，就是对数据表进行操作，组要是二次封装请求的参数consignment，确保提交到数据库时是可靠的。3、xc_consignment_apply_hook_afte：异步回调处理，主要负责通知、缓存更新、资源同步等一列动作，该方法支持外部注册动作钩子，也就是如果有第三方业务需要知道申请结果，可以通过注册方法来接收信息。

消息调整不

消息调整测试

很棒，很可以。很优秀！