宫论项目开发记录

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：异步回调处理，主要负责通知、缓存更新、资源同步等一列动作，该方法支持外部注册动作钩子，也就是如果有第三方业务需要知道申请结果，可以通过注册方法来接收信息。

2025年1月15日
1、通过xc_notify_hook下发寄售回收审核通知，会通过push_data传递以下参数过去：1、配置参数标识（xc_audit_config：consignment）、title：【审核提醒】藏品寄售回收申请、content：XXX申请XX栏目，请及时进行审核处理。user_id：当前申请的用户UID，因为统一的审核通知下发，因此需要再外部传递好对应关键变量参数。
2、寄售回收是两个栏目组，对应的审核机制是存在一些差异的。如果混合在一起进行审核处理，对于后期维护而言肯定会有些混乱，因此审核组做分离处理，除了consignment外，额外增加一个recycle审核配置信息。同时原有的consignment配置参数做出修改调整，名称从寄售回收藏品审核申请，变更为寄售藏品审核申请。
3、新增的recycle审核配置信息如下：1、人工审核场景名称（回收藏品审核申请）2、场景唯一标识（recycle）3、客户人员：这里读取的是藏品分类配置信息，因此默认留空即可。4、审核页面列表：该页面目前还未设计规划好，因此暂且留空，通知事件做好了，就可以做。5、短信提醒+邮件提醒：均设置为开启状态，确保审核员不会有任何疏漏。
4、通过xc_notify_hook下发消息的时候，会根据$consignment['type']来封装push_data数组结构信息，原有的寄售藏品配置信息保持不变，新增recycle回收的通知数组封装。新增的recycle其参数结构其实和之前的push_data也大致保持不变，唯一变化的就两个点。1、xc_audit_config：配置参数从consignment变成了recycle。2、title部分的寄售字眼变更为回收。
5、consignment寄售藏品审核配置（获取待处理的任务），已完成sql的处理。具体参数为：SELECT COUNT(*) AS total_count FROM wp_xc_consignment WHERE status = 0 AND type='consignment'。通过WPDB语句，获取寄售回收表中有关寄售订单的所有待申请的订单数量。注：status=0是待处理的订单状态。type：则是区别寄售回收的关键字段。
6、同样的回收藏品的审核配置（recycle）也完成了待处理任务的sql处理，其参数基本和寄售保持一致。只是在type关键参数区域将consignment变更为了recycle。其原理都是一样，通过wpdb语句获取寄售回收数据表中带哦处理的回收订单的数量。注：不过需要注意的是，寄售和回收都是采用每个分类都可以设定不同的用户，因此需要再读取的计数器的时候，需要做单独处理。确保用户能到的待处理数字是精确的。
7、人工审核通知场景（review）已经全面支持【寄售回收】审核通知的下发处理，基本属于一键集成方案，通过后台配置场景参数，然后在执行xc_notify_hook方法时，传递所需要的参数信息（通过push_data数组进行封装）。便可实现精准下发审核通知到审核对象。注：review通知是统一集成方案，因此下发渠道的支持，需要再配置中进行预设好。默认情况下短信邮件都会下发。
8、review增加一个计数器的功能，计数器的键位设计如下：review_push:$user_id。每个接受到该消息场景通知都会读取是否存在redis缓存，如果存在的情况下，则直接获取。并检测对应的xc_audit_config是否存在，如果存在的情况下则进行计数+1处理，如果不存在的情况下则将其标记为1。然后继续更新redis。该缓存的有效期为365天。该计数器的作用就是记录到处理的审核通知。
9、review_push计数器进行优化，现在的执行流程如下：首先构建 Redis 缓存的键，然后从 Redis 中获取缓存数据。如果缓存数据为空，初始化为一个空数组，取当前配置的计数值，如果不存在则默认为 0，更新计数值（+1），将更新后的数据写回 Redis，设置过期时间为 365 天。优化的重点是减少重复逻辑，提高代码可读性和效率，其执行逻辑仍旧不变。
10、新增一个动作回调脚本：hook_after.php，宫论所有的钩子交互都将通过这个动作回调来进行处理。具体为：当HOOK执行完成了业务逻辑，在返回前端前，会主动触发hook_after事件。在这里可以执行一些非系统的业务处理，比如缓存更新、事件清理、通知下发等行为。这类事件一般采用异步方案执行，因此需要再回调事件中做统一的处理，这个时候hook_after脚本就起到了作用。
11、hook_after的脚本集成方案和之前的hook_before保持一致，都是通过HOOK函数库进行require_once加载，避免主进程直接加载该函数库，造成比必要的性能开支耗损。同时hook_after和hook_before设计逻辑基本一样，一个负责执行前的拦截处理业务，包括第三方业务拦截请求。一个是负责业务完成回调动作，包括第三方业务的通知处理。两者一前一后构建HOOK的的业务能够始终被接管，在不懂核心代码层的基础上，完成拦截接管，和业务回调的扩展处理。

2025年1月14日
1、增加一个全局配置参数：xc_consignment_apply_limit，申请限制条目数，默认值为3。处于待审核的寄售回收藏品，不得大于X条，待审核的申请一旦审核通过，则会主动释放名额。比如限制为3条，但是已提交的申请已达到四条，那么用户最多在提交一条申请（寄售回收共享此处额度）。在申请回进行拦截处理。防止无节制的提交。
2、hook_before处理拦截请求的时候，会使用wpdb语句构建一个sql查询语句，检测数据表xc_consignment当前用户待审核（status）的记录数量是否大于xc_consignment_apply_limit后台设定值，如果大于的话则会执行拦截处理，并返回错误申请失败：待审的藏品不得大于' . $apply_count . '条'。防止部分用户，批量提交无意义的藏品，造成审核的压力。
3、新增一个redis键值：consignment_apply_limit：$user_id。用于系统自动的封禁限制锁，如果用户连续提交的藏品都被官方进行拒绝，那么将会通过这个REDIS进行一个上锁保护处理。上错保护的时间，根据连续被拒绝的次数来决定。后面会提供一个后台配置进行参数处理。大致为连续拒绝3次触发，一般封禁24小时、连续拒绝五次，封禁七天、连续拒绝十次则封禁3个月。在被封禁的期间，将限制用户进行提交申请。
4、hook_before已集成对滥用提交的保护限制，在执行业务前会使用xc_redis_ttl来获取【consignment_apply_limit：' . $user_id】是否存在，如果存在的情况下则表明用户因为泛滥提交被系统做出限制，此时会返回错误【申请失败：频繁提交藏品拦截<br>解封时间:' . $redis_ttl . '秒】。防止用户绕过系统拦截，继续提交无意义的藏品。注：限制计划是递增处理的
5、滥用提交无效藏品被系统封禁规则如下：连续提交的藏品申请（寄售+回收）被官方审核员拒绝，则会标记滥用标识。此时系统会读取后台的预设配置，进行上锁保护。比如限制用户24小时或48小时内进行申请提交。接触限制后，用户仍可以提交申请，但是仍旧被官方拒绝，达到系统的二次上限，则触发二次系统上锁保护。这次将限制时间更长。之前累计的计数是会不断递增。如果期间有藏品通过官方审核，则会重置所有的次数。将其失败表计为0。
6、滥用提交藏品寄售回收请求，提示信息优化：之前是提醒用户XX秒进行解封处理。这个秒数需要用户自己计算下实际时间。非常的不友好。这里改为：系统获取当前时间加上指定秒数后的时间，并以 Y-m-d H:i 格式返回。这样用户能够更直观了解到自己解封申请的时间。注：不管触发哪个阶段的系统封禁限制，其限制的时间都是通过consignment_apply_limit这个redis计算上锁处理。
7、新增一个redis键值：consignment_apply_limit_number：$user_id：当寄售回收申请被官方拒绝的时候，将会通过这个redis进行计数处理。当其数值达到系统配置限制，将触发封禁上锁保护，在一定时间内限制用户继续提交申请，避免一直提交无意义的藏品，造成工作人员的审核压力。这个redis只有两种情况下会释放重置。1、超过60天，自动释放并重置为0。也就是最大限制封禁时间不会超过60天。2、有藏品通过官方审核，系统也会自动重置该参数为0（即重新计数操作）
8、寄售回收的拦截规则（系统级）已基本完成，目前一共有27条拦截规则，对用户的环境、权限、资格、移交的参数做了全方面的检测处理，确保用户提交的寄售回收请求完全符合平台要求。拦截事件采用标准的数组结构返回，code=0代表通过处理，code=1代表未通过验证，msg是具体错误信息。注：除了系统预设的拦截行为外，后续还可以通过动态注册钩子执行额外的拦截动作加载。
9、新增【寄售回收助理】，负责寄售回收藏品整个交易流程的消息通知。包括不限于：申请通知、审核通知、发货通知、收货通知、上拍通知、流拍通知、退回通知、关闭通知、成交通知、费用结算通知。只要涉及到寄售回收藏品的交易走向，都是通过这个站内服务号来下发消息。该助手也只负责寄售回收藏品的消息下发。该服务号不接受私信聊天功能，指定UID为：36.
10、为了审核事件的统一性，避免用户存在多个审核职责是，需要前往不同的页面进行订单审核操作。宫论的审核配置场景新增一个寄售回收类别：具体的参数为，标识：consignment_apply、人工审核场景名称:寄售回收藏品申请、客服人员：为空缺失（这里通过藏品分类来指定审核人员）、审核页面列表:后续新增，目前页面还未进行规划、短信提醒：开启、邮件提醒：开启、获取待处理的任务：为空，后面再执行sql语句的设计。注：统一性处理，可以让所有的审核任务集中正在一个页面处理，方便维护和查看。
11、在完成了媒体文件的动态回调操作后，寄售回收申请钩子事件便进入了通知事件的处理。具体为通过xc_notify_hook下发一个消息通知：接受的消息对象为（$consignment['auditor']：官方分类的审核员，这个参数将根据寄售回收类别、藏品类别读取）、通知的标识为：review（通知审核订单下发）、通知的数组结构push_data，包含了xc_audit_config配置信息参数、title：通知标题的封装处理、消息正文部分：content、user_id：当前的申请寄售回收的用户ID参数值。

2025年1月13日
1、xc_consignment_apply_hook_before事件现在全面接管了寄售回收拦截事件的处理，之前的拦截动作行为也全部迁移到这个方法来处理。后续不管是系统级的拦截，还是外部的拦截行为都通过这个方法来处理。寄售回收仅执行业务的处理，不在负责检测请求是否合法。注：不管是接管动作行为还是本身拦截方法，都需要对结果做出正确的处理响应
2、因为现在都是通过hook_before来负责构建的检测处理，因此返回结果需要特别注意。如果处理失败（因为不具备要求被拦截）则必须返回code=1，并通过msg传递错误的原因。如果整个流程处理下来，全部符合要求也需要返回code=0，方便后续的业务进一步进行处理。在执行hook_before的内部也会对返回结果进行全面接管，根据code来决定下一步动作！
3、寄售配置页面新增一个字段：xc_consignment_open（是否开启寄售申请），如果关闭该选项，则平台不在接收任何寄售申请，这个是全局开关。即便藏品分类开启了寄售功能，但是这里一旦关闭。用户在执行寄售申请的时候仍旧会进行拦截处理。注：已申请的寄售订单，仍旧按照正常流程进行走。只是新的订单不再进行接受。
4、同样的回收配置页面也新增一个字段：xc_recycle_open（是否开启回收申请），如果关闭了该选项，则平台不在接收任何藏品回收申请。这个是全局开关，即便藏品分类已经开启了回收功能，但是这一旦关闭了，用户在执行回收参公申请的时候，仍旧会被拦截处理。注：已申请提交的回收订单，仍旧按照正常流程走完流程，只是新的申请请求会被系统拦截处理。
5、hook_before事件已集成了对寄售回收藏品全局开关的支持，执行寄售回收请求的时候，会根据藏品类别（consignment、recycle）来验证后台是否启用了寄售回收，如果全局关闭了功能模块，那么将直接返回code=1，并文字提示：申请失败：系统暂不开放藏品寄售/回收。
6、藏品分类是否开放寄售回收的申请检测流程如下，首先是通过xc_is_config来读取宫论藏品配置，如果获取不到则直接返回藏品分类不存在的错误提示。如果藏品类别存在则进一步检测其分类是否是属于开放状态，如果平台有这个藏品分类，但是关闭了则表明不在开放。此时返回错误：所属藏品分类不开放。如果是开放的，则检测是否开启了寄售回收的功能，未开放也会返回所属藏品分类不支持寄售。最后就是全局开关的检测处理，如果系统关闭了整个功能模块，则直接返回返回【申请失败：系统暂不开放藏品寄售/回收】。
7、对于藏品类目是否开放的拦截检测现在从最底部的检测处理调整到最上层，避免用户对提交的参数进行逐一对比完成修正后，突然冒出来栏目不开放的错误。造成用户非常不友好的体验操作。从一开始就对栏目做出是否开放进行验证，不管是哪个层级关闭了栏目寄售回收申请，都在第一时间进行反馈处理。只有栏目完全开放，才会对提交的内容进行安全检测。
8、寄售回收的hook_before事件追加一个拦截处理，会通过xc_is_login_phone()方法检测当前用户是否绑定了手机号，如果未绑定则会返回错误提示【请先绑定手机号在提交藏品寄售回收申请】。并且返回的参数会携带jump=phone。前端会延迟2秒直接主动跳转到手机号绑定页面。方便用户在不切换页面的情况下，完成短信验证。并返回到提交申请页面。注：jump是为了避免用户准备的资料，因为绑定手机号的缘故，返回全部丢失。
9、出于业务需求考虑，后台增加一个寄售藏品可选开关字段：xc_consignment_idcard：实名账户才能申请寄售，如果开启了该功能，用户必须完成了账户实名认证的情况下，才能申请藏品寄售请求。这个功能是可选的，可以选择性开启。注：藏品寄售涉及到一系列的交易处理，存在洗钱等金融风险。最好此类交易还是强制要求实名制比较好。避免交易不可溯源，造成平台不可控风险。
10、同样的藏品回收也增加一个可选开关字段：xc_recycle_idcard（实名账户要求），如果藏品回收开启了实名制强制要求，则用户必须完成了账户实名认证的情况下，才能申请藏品回收请求。选择性开关，可以根据实际业务需求来做设定。不过一般情况下还是建议开启，交易涉及到资金流向，如果不做管控会有风险。注：寄售回收两个分离开来做设定，是细分处理。两边都可以根据情况做开关。
11、hook_before已经支持了实名认证的拦截检测处理，如果寄售回收强制要求必须完成实名认证才能提交申请，那么会通过xc_is_login_idcard方法去检测账户已完成了实名认证，如果未完成实名认证（返回false）那么将返回code=1、msg=申请失败：需要完成账户实名认证。同时携带jump参数【real】，要求前端自动跳转到账户实名认证页面，进行下一步操作处理！注：寄售回收是分开设定的，判断拦截也是一样。

2025年1月10日
1、全局push通知配置场景，新增一个通知类别【consignment_apply：藏品寄售回收申请】当寄售申请被成功写入数据表后，将会触发这个消息通知。将下发消息通知给线上审核员，告知对方有寄售回收请求等待线上审核处理。通知渠道目前暂定：邮件通知、站内信服务号、APP消息、模板消息。因为审核通知可能比较多，暂不集成短信通知。
2、寄售回收申请通知限制处理，公众号采用模板消息：订单处理通知：每日限制为10条，超过十条则不在进行下发处理。邮件通知：您有一条寄售回收申请等待处理，每日限制为30封，超过数量则不在进行下发处理。站内服务号通知：无任何限制，可以一直接受，如果在线通过站内信通知，不在线啧通过APP离线消息下发，因为这个消息渠道需要做存档列表，因此通知不做数量下发限制。
3、新增了一种寄售申请拦截方法：xc_is_consignment_apply()。该方法需要传递一个固定变量user_id（申请寄售的用户），其主要目的是为了控制用户提交寄售回收申请的数量和质量，防止这种申请的泛滥，无节制地增加审核负担，并避免大量无价值的藏品被无谓提交。这个方法在内部执行一系列的校验和处理，只有在用户符合预设条件的情况下，才会允许其提交寄售申请。这种限制机制是为了确保线上审核的效率。
4、xc_is_consignment_apply寄售拦截资格检测事件，现在返回标准的数组结构：code=0代表通过检测，允许用户执行下一步执行动作。code=1代表未通过检测，msg是失败的详细。因为拦截机制有很多可能，因此需要通过msg来做消息返回。注：如果返回code=1，则可以直接return返回结果。因为内部本身就是标准的code+msg组合。
5、规范化命名处理，寄售回收资格拦截事件不在集成is方法中，而是改为xc_consignment_apply_hook_before。就是在原来的基础钩子名称后面增加【before：前】意思在执行钩子前，需要先通过这个方法处理。这个方法将标准化，后续的所有的钩子都采用这个标准来处理。如果需要再钩子执行前，执行一系列的处理检测拦截处理，都可以通过加后缀before来处理。注：拦截检测钩子需要继承原有的变量参数，以便进行复杂的业务处理。
6、新增一个脚本文件（hook_before.php）专门负责系统运行钩子的执行前的验证处理方法，也就是XXXX_hook_before的类似处理语法。集中在单独的一个脚本文件中，是为了方便后期维护和扩展的处理。从寄售回收开始，所有的内部钩子事件(服务端）都需要采用这种方法来处理验证机制，这样后期的可扩展性才会变得更高。注：只要是支持before的方法，都将扩展外部接入方案。
7、拦截检测脚本的集成方式是通过HOOK脚本库中直接处理的，具体为在hook.php文件的头部区域使用require_once进行加载【'function/hook_before.php'】完成，这样只有服务端的钩子被触发的商时候才会触发这个检测脚本，可以减少大量请求非必要的引入。节省服务器不必要的性能开支。只有真正需要用到检测脚本才会触发加载动作。
8、考虑到第三方业务可能会涉及到请求的拦截处理，hook_before脚本全面支持xc_apply_filters【宫论过滤动作事件】，在执行拦截动作前，会检测是否进行了动态注册行为。如果有注册扩展行为则会执行外部的接管动作，这样对于扩展性就非常方便，比如寄售回收动作，如果有个业务请求需要接管拦截行为，可以在不修改源代码的基础上，直接通过动态事件完成处理。
9、xc_apply_filters是非常复杂的执行一个方法，封装的原理是：让宫论钩子具备外部扩展能力，实现后期自定义接口集成的方案。后期第三方扩展需求的时候，可以在不动系统内核文件，就可以做到一键接管响应请求。这个是钩子设计的核心部位。但是也需要特别注意一点，xc_apply_filters在处理拦截事件的时候，虽然允许接管。但是这个接管必须是在系统自带拦截行为完成响应处理后，在接入的。例如：在发布评论的时候，系统本身有一套拦截机制，比如：检测用户是否在线、是否允许评论等。但是现在通过xc_apply_filters动态注册一条新的规则，需要检测对方账户是否被作者拉黑，那么必须在系统自带拦截事件执行完毕，才能执行。
10、通过hook_before集成的动态注册过滤事件，必须返回标准的数组结构：即code+msg的组着。code=0外部的拦截规则不生效，允许用户进行下一步操作、code=1外部的拦截规则生效，不允许系统继续往下执行，需要直接放回错误到上一级。并且对应的MSG提示信息，也是必须携带的。因为这个值可能直接要转发到前端，进行页面提示响应。
11、宫论项目已集成了hook_before脚本机制，后续的钩子事件都将采用这套基础做拦截应用场景的处理。步骤多了一步，需要将拦截行为全部通过before脚本来进行处理。但是带来的好处在于。1、拦截事件现在和钩子做分离处理，两者不在混合在一起。2、拦截行为具备了外部扩展能力，后续的拦截检测行为，可以通过外部进行扩展处理。3、更加标准化处理，后续的系统维护起来更方便。

2025年1月9日
1、在通过xc_insert_sql执行数据表插入操作后，系统会将返回的结果（即新的主键ID）赋值给参数变量result_id。在后续的业务处理中，这个变量负责驱动一系列操作，特别是缓存的建立和更新机制。如果通过empty验证，发现该变量为空，这意味着插入操作失败，此时系统会立即返回错误提示，显示"申请失败：数据写入异常"。
2、新增一个redis缓存键位：[contact_person:$user_id]将当前联系人信息数组信息（姓名、手机号、微信号）缓存起来，缓存的有效期为30天，超过30天自动会失效。如果二次执行的话，则缓存的时间会被重置，重新进行缓存更新动作的处理。注：联系人信息，未来很多场景都会用到，这个功能因此非常重要，可以减少用户二次不必要的输入。同时因为联系人数组结构在插入数据表前会进行json转换的处理，因此综合考虑，这个缓存是在写入数据表执行更新的。
3、用户进入寄售回收申请（publish_consignment）页面的时候便会通过get_redis_meta来读取redis缓存【contact_person:$user_id】，如果存在缓存的情况下，则说明用户30天有设定联系人信息，那么此时页面中的联系人表单不需要用户填写，默认输出换成缓存键位信息。注：只是value值的输出，表单并不会进行锁定处理，仍旧可以编辑填写。
4、一旦寄售回收建表成功，那么就进入第一个回调动作。获取寄售回用户提交图片地址列表（$consignment['apply']['image']），然后通过xc_upload_media_ok方法将所有图片进行标记处理，标记的参数为【申请寄售表的主键ID】，通过这样的处理，可以避免图片因为缺失关联ID，被系统因为定时计划而删除。注：为了防止无效图片被过多占用，需要会自动检测没有关联ID的图片，然后将其进行清理。
5、xc_upload_media_ok语法进行优化处理，在执行关联操作的时候，会检测其是否已经关联了order参数，如果关联了则二次更新会被拒绝处理。这样的处理主要是为了防止鉴定报告的图片，一键同步到寄售藏品。进行发布的时候，将原有的图片关联ID进行变更处理，导致出现寄售藏品因为用户或者管理员的原因导致删除，其关联的图片也跟着删除。被删除的图片因为是鉴定图片，造成鉴定报告显示错误异常。
6、xc_is_upload方法进一步进行优化处理，该方法是活通过传递图片或者视频地址，获取其上传数据的方法。直接该方法并不会返回上传记录的关联状态，对于判断是否上传成功非常的不优化，因此做出优化处理。通过该方法返回的信息，会携带status状态标识，可以通过该字段进一步验证是否完成了上传。
7、除了寄售图片会在完成数据表插入后，执行xc_upload_media_ok方法标记图片不可删除外，如果用户上传了藏品实拍图片，也会经过同样的处理。确保其视频也会永久保留下来。两者的执行逻辑基本一致，都是为了防止定时计划将其相关的图片进行删除，导致寄售审核过程中，审核员或工作人员无法播放或查看视频图片。注：两者有个区别，视频是可选参数，因此需要通过empty提前进行验证处理。
8、统一订单查询接口，新增一个方法【xc_query_consignment：寄售回收交易订单查询接口】，如果需要进行寄售回收订单的获取，则必须通过这个方法来处理。该方法会在内部执行wpdb语句，来构建一个sql查询，检索是否存在关联的记录。如果存在则返回对应的寄售回收订单表记录。如果不存在则返回false。注：统一订单查询，减少sql的封装，便于后期的维护处理。该方法需要传递一个固定变量参数ID，主键值。
9、寄售回收表的订单查询方法优化处理，增加第二个变量【uncache：是否禁用缓存，默认为false】即默认情况下该方法为了提升响应速度是支持缓存查询的，在执行过程中会优先通过get_redis_meta来查询是否存在缓存结果，如果存在则直接返回对应的缓存内容。如果不存在则仍旧通过wpbd发起数据库查询请求，但是会将结果保存到reidis键位中，并将缓存时间设定为30天。注：缓存的键位名称为："query_consignment:" . $id。
10、进一步优化寄售回收表的订单查询机制，除了支持ID主键的查询外，现在还支持order订单编号的查询。传递的唯一参数还是ID，但是内部会通过is_numeric方法检测是否为数字字符串，如果是数字字符串的话则进一步验证长度，如果其长度大于9位数则内部构建wpdb方法则使用order进行曲检索，如果小于则通过ID方式去匹配。注：虽然同时支持订单号和ID主键的索引，但是正常情况下还是优先通过ID进行匹配，效果更精确一点。只是多了一个选择。
11、寄售表订单成功生成后，会立即通过xc_query_consignment方法进行缓存刷新处理，以确保后续的订单读取可以获取到最准确的数据。同时在插入寄售订单前会通过xc_is_order的方法来获取一个随机单号，并将其保存到$consignment['order']作为该寄售订单的唯一交易号。注：交易号是展示给前端用户看的，无论是寄售审核员、上架员、申请人、交易员。所看到的寄售订单唯一标识，都是这个ORDER。

2025年1月8日
1、在执行数据表写入前，会根据type请求类型来写入staff字段，该字段参数为工作人员。系统会根据藏品分类和藏品类别来设置工作人的UID，这里因此也要写入相对应的工作人员的UID，以确保整个流程能够被顺利执行下去。staff这个字段是数据表对应工作人员的ID，在完成寄货动作后，将会下发通知和业务处理给工作人员，以便其接管整个藏品的寄售回收操作。
2、宫论全局配置页面新增一个配置数组【xc_address_config】官方的收件地址，可以根据业务需要配置收货人地址信息。一共有四个字段需要填写【title：收件场景名称，比如寄售服务。key：唯一标识不可变更处理。name：收件人姓名、phone：收件人的手机号、address：详细地址信息】后面需要用到的收件服务会有很多，因此做成数组结构，灵活变动。方便后续的业务接入。
3、xc_address_config官方收件地址配置，除了基础的五个字段外，额外增加四个参数字段：分别为（province：所在省份、city：所在城市、region：所在地区）。现代化标准的快递下单接口，是需要地理位置的，如果通过详细地址去进行解析，可能效果并不是很理想，万一出错会导致一系列的问题。因此从一开始就规范化，可以减少很多问题。
4、为了确保的可控性，寄售回收参数配置组，新增两个字段【consignment_address和recycle_address】分别对应的是寄售服务的官方收件地址信息和回收服务的官方收件地址信息。这两个参数对应的是新加入的xc_address_config配置的KEY标识，通过这样的处理，平台可以定义每个藏品分类的处理地址。比如瓷器藏品需要寄给北京的工作人员，玉器需要寄给山东的公司。并限制所有的藏品都必须在一个地方处理。加上人员的自由配置机制，线上审核和线下上架可以取决于平台和官方合作伙伴。
5、后台的官方收件地址配置中心，新增两个通用收件地址参数做为测试使用，分别对应的是寄售服务的官方收件地址（consignment）和回收藏品官方收件地址（recycle）。这两个地址仅限于测试使用，后面正式运营上架，将会进行删除。同时对应的分类关联参数也会移除。当用户提交藏品寄售和回收服务的时候，官方读取的寄出地址就是测试地址。
6、xc_address_config配置额外增加一个字段：remake（收货地址备注信息），用户在进行寄件填写单号的时候，如果设置了备注信息，则会在页面高亮显示这个备注信息，可以在这里填写一些备注说明，比如官方不收取到付件，快递必须进行保价、发货请自行录制好实物实拍图、快递运输出现问题需要自行处理。等等，不同的寄件的服务，可以填写不同的备注信息。
7、整个寄售回收服务是具备极高的自定义选择的，每个藏品分类都可以选择开启寄售或者回收服务，开启的类目，可以指定不同的寄售审核专家和回收审核专家。并且工作人员也是一样，可以根据不同的类目来设定不同的线下工作人员。官方收件地址同样也是如此，可以根据实际的需求，设定不同的收件信息。通过设定审核专家、线下工作人员、官方收件地址。来指派不同的合作伙伴来处理藏品寄售回收处理的业务逻辑，如果全部走官方，只需要将参数设定统一即可。如果某个藏品类别需要由指定合作伙伴来完成，那么将所有的信息设置为它的即可。
8、因为官方收件地址非固定化处理，因此通过xc_consignment_apply_hook申请寄售回收处理请求时，会根据type的来源类别来处读取后台预设的收件参数信息，并最终将标识写入到official_address参数中。同时会在封装数组时，尝试通过xc_is_config地址配置参数，如果配置读取失败，则会直接返回错误：申请失败：官方的收件地址信息异常，联系管理员处理。
9、consignment数组完成所有的参数封装后，会使用通用语法xc_insert_sql进行数据表插入动作，并对返回结果进行监听处理。如果返回未false，则阻止后续的执行，并提示错误【申请失败：数据表写入失败（联系客服处理）】。如果返回ID则表明本次寄售申请，已成功写入到数据表。则继续执行下一步动作。注：consignment是每一个字段都对应的是数据表的键位，因此需要仔细对比检查。
10、在进行xc_insert_sql数据表写入的时候，增加一个字段转化处理过程。因为有部分字段【apply：申请资料、time_summary：时间汇总参数、mata：自定义扩展字段】是json结构方式存储的，如果直接使用数组方式进行数据表的写入，会返回异常。并且后续的读取会出现一系列的错误。因此这三个字段在插入数据表之前，会进行json转换。确保能写入正确数据到字段中。
11、在执行寄售回收表插入动作的时候，会将status字段初始化为0。表明这个寄售回收订单，目前处于待审核状态。待审核的订单列表，也将以0作为筛选对象来读取所有待处理的订单记录。当订单发生变化的时候，这个status字段也会发生变化。比如用户取消订单、审核员拒绝、审核员同意等。注：status控制订单状态变化，因为场景业务非常复杂，可能有多达十几种变化，每种订单状态都要处理好。

2025年1月7日
1、在前端提交的基础参数校验完成后，将封装创建两个参数。首先是“time_summary”，它是一个时间汇总数组，其中包含了一个为“apply_time”的字段，表示申请寄售的具体时间，格式为“Y-m-d H:i:s”。这个时间汇总数据整体采用JSON结构，记录了多个时间参数，方便进行汇总统计。其次是“time”，同样表示寄售时间，但它是一个单一的固定值，便于后续的时间筛查使用。这两个字段都记录了申请寄售的时间，但二者在用途上各有侧重：time_summary适用于复杂的时间数据分析，而time则更适合对单一时间节点的筛选和判断。
2、在处理寄售申请请求时，系统会首先检测apply_type和apply_order两个变量的值，这两个变量分别用于标识藏品的来源和关联的单号。当这两个变量存在值时，意味着该寄售回收请求是由某个渠道发起的，而不是来自用户的直接申请。在这种情况下，系统会读取来自前端的提交信息，并将这些信息写入数据库中。但是，如果这两个变量不存在值，则说明请求是用户通过常规流程提交的。为了确保系统的稳定性和防止出错，当检测到变量不存在时，系统会将apply_type和apply_order的值标记为NULL，以便后续操作能够顺利进行并避免潜在的数据处理错误。
3、寄售回收表中的type字段目前设定为两个固定参数：1. 寄售订单类型（Consignment），2.回收订单类型（Recycle）。由于这两种类型的交易流程基本相同，仅在结算方式上有所不同，因此为了便于维护，合并到一个表中进行处理。通过type字段的固定值来区分不同订单的类型。当通过xc_hook_consignment_apply发起藏品寄售请求时，系统会自动将consignment['type']标记为相应的Consignment类型，以方便服务端进行后续的业务处理。
4、在宫论全局的藏品分类配置字段【xc_category_config】中，新增了两个重要的字段配置参数：第一个是“recycle”，此字段用于决定是否允许指定分类的藏品进行官方回收。当此选项开启后，用户可以将其藏品提交至线上平台进行报价评估，经过官方确认后，将对此类别的藏品进行回收处理。第二个新增字段是“recycle_auditor”，即回收审核员。此角色负责对线上提交的藏品进行审核，只有在审核员完成审核后，藏品才能最终被判定为可进行官方回收。
5、修复了"consignment_auditor：寄售审核员"和"recycle_auditor：回收审核员"在配置中字段类型设定错误的问题。此前，这两个字段被误设定为switcher选项开关类型，导致在配置页面上无法正确设置参数。经过修正后，这两个字段的类型已更改为spinner，以便工作人员输入UID。此外，回收审核员的选项现已被调整为仅在开启回收功能时才会显示。
6、寄售回收钩子现在会对前端传递的type进行参数效验，如果其参数为【consignment】则表明本次订单是寄售申请，那么将检测$category_config['consignment']是否开启，如果未开启则提示（错误：所属藏品分类不支持寄售）。如果其参数为【Recycle】则表明本次订单申请是回收，那么将检测$category_config['Recycle']是否开启，如果未开启则提示（错误：所属藏品分类不支持回收）。
7、为寄售和回收钩子新增了一项重要的拦截检测机制，以增强系统的稳定性和安全性。在用户进行寄售申请时，如果后台未配置审核员，该系统将自动返回错误信息：“藏品寄售审核员参数未配置，请联系管理员处理。”这一机制确保任何寄售申请在缺乏审核员情况下不会被提交，避免后续操作出现混乱。同样的处理逻辑也适用于回收订单：当进行回收申请而未配置审核员时，系统会给出相应的错误提示：“藏品回收审核员参数未配置，请联系管理员处理。”这个基础拦截功能的引入是为了杜绝由于审核员缺失而引发的系统错误或流程中断。
8、在xc_consignment数据表中，有一个重要字段名为“auditor”，此字段用于记录线上审核专家的UID。审核专家的分配是通过后台参数指派，目前主要涉及寄售审核员和回收审核员两类角色。系统会根据订单的类型，从后台读取相应的预设工作人员，并相应地赋值给该字段。如果对应的审核专家信息缺失，系统将会产生错误返回，并终止后续的执行流程。一旦信息存在，系统会继续验证该审核员的UID是否有效，并检测其账户状态是否正常可用。如果审核专家的账户不可用，系统同样会返回错误提示。
9、contact_person联系人的信息字段是在用户申请寄售或回收时，系统要求用户必须填写的一份表单。这些信息会被存储在数据表的meta字段中，具体结构参数为$consignment['meta']['contact_person']。在输入时，信息以数组形式存入，随如果符合条件则将其转为JSON格式进行存储。后续如果需要从数据表中提取联系人信息时，需首先读取JSON字符串，然后将其转换为数组格式以便处理和使用。
10、申请寄售回收钩子 xc_consignment_apply_hook 已经完成了对所有参数的完整封装处理。这些参数主要是通过前端提交的，钩子的功能则是对这些参数进行校验检查。此外，少部分参数由内部方法进行构建和处理。所有参数都被封装到名为【consignment】的数据数组中。具体的参数包括：type（寄售回收标识）、apply（申请资料）、time（申请时间）、expected_price（期望售价）、auditor（专家审核）、time_summary（时间汇总）、meta（扩展字段）、apply_type（申请来源）、apply_order（来源单号）以及 cat（藏品类型）。
11、无论是寄售还是回收流程，都需要指派线下工作人员进行全程跟单处理至关重要，包括收件后的签收、线下到货的审核、重新拍照和补充视频资料、出具权威鉴定报告，及与寄售方协商商品上架和出售相关事宜。原本，这些任务通常由固定的人员负责，无论藏品的来源类型或分类如何。但是后续考虑到业务量的增加，这种安排可能无法负荷，因此决定引入一个灵活调度机制。此机制允许根据藏品的分类进行参数化配置。具体的实施细节是，在分类配置中增加两个字段：recycle_staff（负责回收的工作人员）和 consignment_staff（负责寄售的工作人员）。

2025年1月6日
1、在后端的寄售申请流程中，钩子事件被设计为在初始化时即设置result变量，以便在遇到错误或无权限操作时，可以及时通过result数组进行参数返回的处理。在执行钩子事件的过程中，会调用xc_is_login函数来检查用户的登录状态。如果用户尚未登录，系统将返回code=1，并提供相应的错误提示信息。值得注意的是，无论在任何情况下，只有在用户处于登录状态时，寄售钩子才能被成功执行。这一机制确保了操作的安全性和用户权限的合理性。
2、在寄售申请的处理过程中，系统会调用xc_is_security方法对用户的操作环境进行安全性检测。如果该方法判断结果为false，意味着用户当前的环境并不安全可靠，因此系统将立即返回错误信息【设备环境不安全，需要短信验证。】并阻止后续请求的执行。与此同时，系统还会返回一个名为jump的参数，其值为security。前端在接收到该参数后，会自动执行页面跳转，引导用户进行必要的短信验证程序，以确保安全的用户交互。
3、在宫论账户的功能限制配置组中，新增了一个特定场景设定【consignment：寄售功能】。这一功能的引入使得普通管理员可以灵活管理用户权限。平台赋予管理员对用户寄售功能进行限制的能力，一旦寄售功能被限制，用户将无法发起寄售和回收请求。这项功能的设置是基于账户具备的细化封禁处理能力，以便精确应对用户的违规行为。例如，在某用户因违反规定而需要处罚时，可以选择只限制其朋友圈功能的使用，同时保证其他功能的正常使用。这种封禁机制通常作用于一个较小的时间范围，如三天或七天，使得用户在短暂的限制期过后可以恢复完整功能使用。
4、在寄售过程中，系统会使用is_account_status参数对当前用户的状态进行验证，以判断其是否具备使用寄售功能的资格。如果检测到账号状态异常，如被拉黑、封禁或被限制寄售功能，系统将会立即触发拦截，阻止后续业务操作的进行。同时，系统会在返回的消息中，详细提示用户账户异常的具体原因。如果账户封禁不是永久性的，系统还会贴心地告知用户具体的解封时间，让用户了解何时能够恢复使用寄售功能。
5、寄售的过程中，会使用xc_publish_textarea_config方法来获取consignment的配置场景参数，如果本次用户提交的藏品鉴赏描述信息【$consignment['apply']['remark']】出现以下状况则会进行拦截。1、$config['least']配置我不看0，但是提交的描述信息为空，返回【错误：鉴赏描述不得少于 ' . $config['least'] . ' 字】。2、使用xc_is_html验证提交的描述信息，如果存在非法字符则返回【错误：鉴赏描述存在非法字符】。3、使用mb_strlen获取文本长度，一个中文算一个字。并与配置进行参数对比，如果少于或者多余限制要求，则会触发对应的提示错误。告知用户自述过多或过少。
6、用户在通过remark提交较长文本信息时，由于这些信息将被多个环节的用户或工作人员查看，因此如果内容中存在纰漏，可能会引发严重的问题。因此，对内容进行敏感词检测处理显得尤为重要。我们采用的方法为：xc_sensitive_words，对文本进行全面检测。当检测到存在敏感词时，系统将自动拦截该信息，并提示相应的错误信息，从而防止用户在不知情的情况下直接提交可能导致不良后果的内容。
7、寄售藏品图片的处理，系统强制要求用户上传寄售图片，如果对应参数为空【$consignment['apply']['image']】则直接回返回错误：错误：藏品实拍图片不能为空，然后使用xc_is_config方法获取寄售图片上传配置场景参数，并对藏品图片进行数组切割处理，并统计其数组数量，如果用户提交的藏品图片小于系统限制，或者大于系统上限 则会主动提示【错误：藏品实拍图片不能低于或大于' . $image_config['least'] . '张'】
8、在寄售流程中，用户需选择藏品所属的分类。如果该寄售请求是在其它场景中发布的，系统则会自动锁定相关设置。当服务端处理寄售请求时，会检查是否有通过empty函数验证前端传递的$consignment['cat']参数。如果该参数为空，系统将直接返回错误提示：“错误：藏品分类未选择”。值得注意的是，藏品分类是一个至关重要的参数，后续的多个场景处理，如拍卖等环节，都将依赖于此项的正确设置。
9、当用户选择了藏品分类后，系统将读取配置文件 xc_category_config 以获取相应的分类配置信息。若未能查找到相应的配置信息，将返回提示【错误：所属藏品分类不存在】。若查找成功，系统将进一步验证该分类栏目是否设为开放状态（通过检查 $category_config['open']）。如果栏目并未开放，则返回提示【错误：所属藏品分类不开放】。随后，系统还需检查该栏目是否已开启寄售功能。如果未开启寄售功能，将返回错误提示【错误：所属藏品分类不支持寄售】。
10、在寄售过程中，有一个可选参数叫做 consignment['expected_price']，即期望售价或心理底价。这个参数可能会遇到以下几种情况。首先，如果后台没有启用此功能，则用户无法看到相关输入表单，这意味着不提供输入底价功能。其次，如果后台已启用但用户未填写，则需要进行空值检查。如果为空值，可以直接将其设置为0以避免后续处理出现问题。而在用户填写了值的情况下，需要使用 is_numeric 函数仔细验证这个输入参数是否为数字，确保其为有效的整数输入。若输入含有非法字符或不是数字型数据，则应当及时向用户提示错误信息，以确保这个参数的处理是正确且可靠的，避免因参数设置不当导致的任何潜在问题。
11、寄售藏品申请需要填写contact_person表单，其中包括三个固定项目：联系人、手机号和微信号（微信号可以选择填写）。服务端将对这些参数进行严格的正则匹配验证：首先，姓名必须是中文字符且长度不得超过7个字；其次，手机号码必须为符合格式的中国内地11位数字；最后，微信号长度不得超过20个字符。注：联系人字段存储于$consignment['meta']['contact_person']数组中。

2025年1月3日
1、寄售视频地址获取方式已成功处理。当通过 xc_hook_consignment_apply 提交申请时，系统将调用 xc_video_url_get('consignment') 方法，检测页面是否已上传视频文件。如果页面未上传视频，而系统又强制要求必须提供视频时，将在页面上显示错误提示【申请失败，请先上传视频】，同时返回 false，以阻止后续流程的执行。
2、在进行藏品寄售时，系统会严格要求用户填写详细的描述信息。用户在提交审核的过程中，系统通过调用 xc_textarea_url_get('consignment') 方法来提取对应文本框的内容。如果该内容获取失败，系统将会提醒用户必须填写相关信息。这一文本框的描述信息有着字数限制要求，过长和过短的信息都会被视为不合格。因此，在成功提取到文本字符串后，系统会进行长度检测，确保其符合规定的标准，只有在合格的情况下，流程才会进入下一步骤。
3、在完成表单内容处理之后，将使用xc_is_protocol来检测页面中是否已勾选【藏品寄售协议】。如果用户未勾选该协议，系统将中断当前处理，并返回错误提示：“请先勾选[页面相关协议]”。需要注意的是，藏品寄售协议涵盖了账户结算、结算方式、交易流程以及退货处理等一系列重要问题，因此要求用户主动勾选同意此协议。只有在用户认可并勾选协议后，才能继续进行寄售操作的申请。
4、期望售价是一个可选项，需要根据不同的业务场景由后台来决定其是否开启。因此，在有些情况下，它可能会显示，而在另一些情况下则不会。在进行表单封装处理时，首先会检测页面中是否存在对应的框元素。如果该框元素存在，那么才会进一步检测其输入框的内容。如果输入框中的内容为空或输入框根本不存在，则系统会默认将其标记为0，并将这个结果保存到"expected_price"变量中，以便进行后续的处理。
5、最后，对表单进行了封装处理，其中关键部分是【contact_person：联系人信息】。联系人信息包含三个字段：name（姓名）、phone（手机号）和 weixin（微信号码）。这些信息采用子数组对象的方式进行存储，这种结构设计不仅直观，且在处理和调用时非常方便。格式上，使用例如 consignment['contact_person']['name'] 的方式来访问具体的联系人信息，确保数据的组织和提取都能高效进行。
6、contact_person联系人表单将进行基础参数验证处理，其中联系人姓名必须为中文，并且字数不得超过10个字。联系手机号则通过正则表达式检测其格式是否合法，若格式不符，将提示相应的错误信息。微信号作为可选参数，只要字数不超过15位即可视为合理。仅在所有字段类型符合要求的情况下，数据才会被存储到consignment数组中，随后进入最终的ajax请求阶段。
7、为了确保前后端参数的一致性，在将数据提交到服务器并完成参数验证后，可以直接使用 consignment 数组作为插入对象。新增了两个子数组来保存申请信息和联系人信息，具体如下：首先，consignment['apply'] 是一个用于保存申请材料的数组，包括图片、视频和描述文本框，这些信息都会存储在一个字段中，后续将采用 JSON 结构进行存储。其次，consignment['meta'] 是一个自定义的数组结构，用于存储用户的联系人信息，这些信息会写入到数据表中的 meta 字段，并使用 JSON 结构。
8、在寄售回收表中新增了一个名为"cat"的字段，以用于记录藏品的类型。此字段采用 VARCHAR(32) 类型进行存储，并已经被加入到组合索引列表中。作为一个关键字段，它用于保存宫论通用分类的KEY，这一参数对于识别和管理提交寄售的藏品类别至关重要。由于在之前的规划中遗漏了这个字段的写入，现已紧急补充，以确保系统的完整性和数据的一致性。新增字段对应的参数为consignment['cat']
9、寄售藏品的申请可以通过多个渠道进行，例如在淘货交易界面或鉴定页面一键申请。不同渠道有各自的参数标识，用于对其进行区分。如果采用默认方式提交申请，即通过寄售申请页面主动填写资料，则apply_type参数将被标记为default。这一标记用于表明此次寄售申请是通过默认的提交方式进行的。在提交到服务端进行业务处理时，该参数变量会被赋予相应的值。
10、在前端完成对consignment数组的封装之后，即刻触发AJAX请求，并将consignment数组作为参数提交至宫论API接口。接下来的业务逻辑则交由服务端进行全面处理。一旦服务端处理完毕并返回结果，前端将执行相应的页面交互动作。鉴于该业务流程的复杂性以及需要等待服务端的响应，为了避免用户在此期间进行误操作，系统会通过调用xc_loading_show来显示一个遮盖层，指示“正在处理中”。在此过程中，页面将被锁定，禁止用户进行二次点击。一旦服务端返回结果，遮盖层将自动关闭，恢复用户交互。
11、新增后端钩子：xc_consignment_apply_hook，专门用于处理寄售藏品的相关业务流程。此钩子负责多个关键步骤，包括参数的严格检验、请求合法性的全面审查、数据的精确插入以及必要的回调通知等处理环节。钩子所需的consignment数组参数由前端用户提交的表单生成，因此其内容多样且复杂，这要求该钩子在执行过程中对每个步骤进行细致的处理。执行结束后，该钩子将返回一个标准化的数组结构：其中，code=0表示申请成功提交，而code=1则表明申请处理失败，msg字段用于提供具体的错误详情。这一设计旨在确保整个寄售过程的透明性和可靠性。

2025年1月2日
1、我们修复了在执行 xc_publish_post('consignment') 事件时访问寄售回收申请页面出现的错误，此错误导致页面出现【解析错误：语法错误，意外的单引号字符串】并产生致命错误。问题的根源在于期望售价box容器在输出判断时未能正确闭合参数，导致异常溢出。目前，该问题已成功修复，确保页面正常运行。
2、联系人输入表单样式封装完毕：margin: 2vw;: 设置元素的外边距为2视窗宽度单位（vw）。vw是基于视口宽度的相对单位，元素的边框有5像素的圆角，为元素提供一个圆滑的角落效果、强制将元素的顶部外边距设置为3视窗宽度单位、元素边框的样式为实线、元素边框的宽度为1像素、元素底部的外边距为5视窗宽度单位。
3、期望售价表单样式封装完毕：设置元素的外边距为3视窗宽度单位、内边距为3视窗宽度单位、元素的背景颜色为浅绿色，使用的是16进制颜色代码、元素的边框圆角化，弧度为2视窗宽度单位，使得角变得更圆滑、文本的字体大小为3.5视窗宽度单位、字体颜色为中等灰色，接近于图形界面中的中性色调、元素的底部设置一个为2视窗宽度单位的外边距，可能用于覆盖先前通配的margin值，创造一个更大的底部空间。
4、为了提高用户输入的准确性，将期望售价的输入框类型（type）设置为number，只允许输入数字类型的内容，从源头上防止用户填写非法参数。此外，还通过设置pattern属性为[0-9]*，进一步确保用户不能输入非数字的字符。为了引导用户更好地理解输入框的用途，placeholder默认提示为“货币单位(人民币)”。为了帮助用户合理设定售价，在输入框的最右侧添加了一个提示按钮，当用户点击该按钮时，会弹出提示信息：“请合理设置心理底价”，确保用户在输入售价时能做出符合自身经济预期的选择。
5、表单ID标识，基本遵循寄售表的字段类型的来设定。分别为（寄售价格：expected_price、联系人：contact_person_name、联系电话：contact_person_phone、微信号：contact_person_weixin）藏品图片、视频、描述以及分类，因为是通过组件生成，无法定义ID参数。但是在提取参数的时候会以数据表字段为准。确保后续业务插入的时候，可以直接使用，减少二次封装的处理。
6、寄售藏品申请的页面表单已全面完成封装。在正常情况下，用户如果希望提交一份寄售申请，需要详细填写以下参数信息：首先，用户需选择所寄售藏品的分类；其次，必须上传藏品图片，并且图片数量需要达到最低要求；此外，用户也可以上传藏品实拍视频，虽然该项可设置为强制上传；然后，用户需填写寄售藏品的补充描述，这是必须的；接下来，用户必须填写期望售价的相关参数，以及提供完整的联系人信息，包括姓名和手机号码。此过程确保每一份寄售申请都可以准确无误地提交和处理。
7、前端新增了一个名为 xc_hook_consignment_apply 的钩子，这是一个极为重要的功能点。用户在提交藏品寄售申请之前，必须首先通过这个钩子进行参数的封装和基础的前端验证。如果提交内容符合要求，则会触发AJAX请求，将参数发送到后端进行进一步的处理。藏品寄售和回收是平台初期的重要业务之一，因此，作为唯一的申请钩子事件，这个钩子尤为关键，尤其是在确保参数验证正确性的过程中发挥着核心作用。
8、xc_hook_consignment_apply钩子的基础拦截规则目前有三个。1、通过xc.is_login验证用户是否已登录，如果未登录的话则触发【xc_login】事件，强制用户进行登录。2、使用xc_is_last_page获取用户当前所在页面，如果不等于publish_consignment则视为非法请求。3、建立元素锁定page_content变量，位置为【publish_consignment_content】如果获取失败也返回异常错误。
9、在提交寄售藏品的钩子执行过程中，系统会首先初始化一个名为【consignment】的作用域变量，所有相关参数均将以数组的形式存入该变量。执行的首要步骤是通过publish_component_category li.on方法从页面上提取当前选择的藏品分类，并存储在consignment['cat']中。接下来，系统会进行一次验证，以确保藏品分类已被选择。如果发现此字段为空，意味着用户尚未选择任何藏品分类，此时系统将触发提示信息【申请失败：请先选择藏品分类】，同时中止后续流程的执行。
10、寄售藏品的图片检测处理已完成处理，具体流程如下：1、首先通过xc_publish_image来判断当前页面是否存在上传组件，如果存在的话则检测组件中是否有包含 `blob` 的 <a> 标签，如果有则表明有图片未上传成功。返回错误（申请失败：有图片未成功上传!）。2、使用xc_image_url_get方法获取页面中成功上传的的图片数量，并将其保存到consignment['image']。注：xc_image_url_get方法会自动读取图片列表，并完成切割。返回符合要求的图片地址字符串，减少处理。
11、成功获取到用户上传图片列表字符串后，会对其进行三个验证处理。确保用户提交的图片数量符合要求。1、如果字符串返回为空，则说明用户未上传图片。拦截并提示，申请失败：图片不能为空。2、通过提取页面的quantity参数，并对字符串的图片数量做统计处理，如果大于该值返回错误提示。图片超过限制。3、通过提取页面的least，并进行验证对比，如果上传图片数量小于该数值则提示【申请失败：寄售藏品图片至少提供X张】

2025年1月01日
1、在xc_consignment藏品寄售回收表中，新增了组合索引机制。这些索引涵盖了商品类型（type）、申请用户（user_id）、订单唯一标识（order）以及状态（status）等字段。通过这种结构化的索引布局，能够显著提高数据检索和读取的效率。大多数情况下，这几个字段构成的查询条件是获取相关内容的主要途径，因此将其设置为组合索引，能够有效减轻数据库的查询负荷。此外，ID字段已经作为唯一键值，自带主键索引的特性。
2、寄售回收表涉及多个场景渠道的申请，因此需要针对不同类型的申请建立相应的数据索引。这种做法可以在进行数据分类和筛选时显著提升内容查找的响应速度。基于这一需求，增加第二个组合索引模块，其中将包含apply_type（申请来源）和apply_order（来源单号）两个关键字段。通过这一模块的构建及优化，在处理来源类型数据时，系统的响应和执行速度将会得到提升。
3、后台寄售回收配置新增字段：xc_consignment_publish_price（寄售藏品期望价格）switcher开关选项，默认关闭，如果开启，在申请藏品寄售的过程中，将会在强制用户填写期望售价，后续的藏品上拍，将会以这个价格作为底价，作为保护处理。防止价格出售低于用户心理预期。注：这个功能是个灵活开关，防止后期变动。目前应该是关闭处理。
4、寄售藏品一旦审核通过是需要寄到宫论平台线下处理，如果只是单纯的提交藏品图片，不一定能够真实看到图片的状态。而且可能用户提交网图来干扰，因此后台新增一个字段：xc_consignment_publish_video（是否强制用户上传视频），如果强制上传视频，那么提交申请必须附带对应的视频。注：可以更深入的验证，强制用户提交视频的时候，在藏品旁边放一张纸片，填写账户UID，来确保藏品的真实性。
5、寄售藏品申请页面，如果检测到【xc_consignment_publish_video】字段是true值，则会在xc_upload_video_html构建方法的时候，显示一段tips提示信息【寄售藏品需要提交藏品的实拍视频，以便官方审核】。如果为false，则无此提示信息。与之对应的，服务端在处理寄售请求的时候，会将这个作为拦截保护。
6、当后台启用了寄售的【期望价格】功能后，用户在申请寄售时，页面将自动添加一个额外的box容器，命名为【expected_price】。在这个容器中会显示一个输入表单，用于填写期望的售价。为了确保提交的完整性和有效性，用户必须在这里输入一个数字单位的期望售价，只有在填写了这个表单后，才可以提交寄售申请。如果后台没有启用期望售价功能，则该表单将默认被隐藏，以防止用户发送非法的提交请求。
7、如果开启了期望售价，在expected_price容器中会显示一条提示信息：在填写您的寄售藏品心理价（底价）时，请务必仔细考虑。平台会依据藏品的具体信息进行专业评估，只有当您设定的期望价格符合评估标准时，寄售请求才会被批准。请留意，这一价格仅为初步参考，并不保证为最终的成交售价，平台也无法承诺最终的销售价格将与您设定的期望售价一致。
8、在寄售过程中，可能因资料不全或交易问题需要联系用户，然而，通常平台绑定的手机号未必能快速找到用户。为此，在寄售藏品栏中新增一个box容器(Contact_person)用于收集联系信息，要求用户提供“联系人”和“联系电话”这两个表单信息。填写的信息将被记录在寄售回收表的meta字段中。这一增加的功能能够保证在交易过程中，若需与用户确认信息，平台工作人员可通过记录的联系人信息迅速与用户取得联系，以便问题的及时解决。
9、在寄售藏品页面的联系表单中，除了必填信息（如手机号和姓名）外，新增了一个可选的微信号字段。用户若填写此字段，将可以优先通过微信与其进行联系。这项改动旨在提升沟通效率，因为在交易过程中，可能需要用户补充一些材料，而通过微信与用户沟通，可以更迅速地解决相关问题，从而提高用户体验与交易顺畅度。
10、在用户的手机号码已绑定的情况下，联系人表单将优先展示【已绑定的手机号码】，以最大限度地减少用户的重复输入操作。只有在用户认为绑定的号码不再常用时，才需再次输入新的号码。此外，即将引入一个基于 Redis 的缓存设计，用户在首次填写联系人信息（包括微信号、手机号、姓名）后，这些信息将被缓存到个人资料中，有效期为30至90天。在此期间，系统默认从缓存中读取用户的联络信息，以简化用户体验并提高操作效率。
11、在宫论藏品分类配置中，新增了一个重要字段【consignment_auditor：寄售审核员】。此字段的引入意味着该分类的寄售申请将由指定的审核员进行线上审核。审核员的职责是评估藏品是否符合平台的收录标准。若符合标准，藏品将被寄送至平台进行进一步处理；若不符合，则会驳回申请。审核员可以是专业的鉴定专家，也可以是平台的工作人员。为了激励审核员，平台在完成订单交易后，可能会给予一定的奖励或分成。此外，需注意的是，如果consignment字段为false（即不支持寄售），则【consignment_auditor】字段将默认隐藏，不会显示在用户界面中。

2024年12月31日
1、为了优化寄售过程的数据信息管理，表格中新增了一个名为express的字段，用于记录快递单号信息。该字段采用了JSON结构设计，能够灵活地存储与不同快递行为相关的多组快递单号。在寄售过程中，可能会涉及多个交互阶段，例如用户将商品发给官方，或因某种原因官方需要将商品退回给用户。使用JSON结构可以有效地集中管理这些信息，避免因增加字段而对表结构造成额外负担。这一设计不但简化了数据管理流程，还为后续数据检索和处理提供了更高效的支持。
2、快递信息的存储结构设计如下：包括快递公司名称（name）、快递单号（code）、快递发货时间（time）、快递表主键（id）、以及快递的标识。未来计划以字典形式进行存储，以便更高效地管理数据。无论是由官方寄出的快递，还是用户自行寄出的快递，所有信息在写入express字段时，都会按照上述结构进行记录。在这些字段中，快递表主键（ID）尤为重要，因为它是进行物流追踪的核心识别信息。
3、在寄售回收表中新增了一个名为“payment”的支付字段，类型为整数(INT)，该字段用于存储支付订单表中的主键ID。这个字段在用户寄售的过程中至关重要，因为它直接涉及到用户主动取消订单时的费用处理。具体来说，当用户发起寄售后，藏品签收并进入交易流程后，如果在此过程中需要退货，用户将承担官方鉴定费用以及退回快递费用。这些费用被视为用户的违约支出，由用户支付，并记录在该支付字段中，以便后续财务对账更为便捷和准确。此措施旨在规范交易流程，并确保各方在发生违约时有明确的费用承担责任。
4、新增字段transaction_amount（订单成交额）到寄售回收表中，以用于记录当一个交易订单完成并通过平台成功售出藏品时的成交金额。同时，对于成交的付款订单，将使用字段transaction_payment来记录相应的数据。通过这两个关键字段，用户可以轻松获取与支付订单相关的信息，确保平台上的交易数据清晰、透明，便于后续的财务分析和核算。
5、为优化财务管理流程，新增了【settlement】字段，专用于存储收益结算记录。当平台成功促成寄售或回收交易时，系统将进行收益结算处理。结算完成后，相关信息将写入结算表中，详尽记录订单总金额、用户所得金额、平台佣金收益以及结算时间等重要数据。此外，为了简化对账流程，这些结算记录的ID还会被同步写入寄售回收申请表中。
6、在完成寄售藏品交易后，不仅需要记录结算账单信息，还需要在数据表中通过【transaction_income】字段记录一个关键的数据，即用户在这笔订单中实际收到的款项（成交收入）。由于寄售回收的账单结算可能存在不一致，并且分类藏品的设定各有不同，导致每笔交易的结算金额各异。因此，设定这个字段是为了明确展示用户订单的实际收益。如果需要更详细的结算记录，则可以通过已存入的数据表中原有的结算账单进行查询，以获取全面的信息。
7、同样的，xc_Consignment（宫论寄售藏品表）也将新增一个字段commission【账单佣金】，用以记录平台在此订单上实际获得的收益。由于结算方式较为复杂，涉及到不同的交易方式以及藏品类型的多样性，一旦藏品交易完成，系统将自动进行结算处理，计算出平台的实际收益，并将结果写入commission字段。这一改动将大大方便后续的账单统计与财务核算，使平台的收益管理更加高效和精准。
8、寄售藏品的交易过程复杂多样，涉及众多交易场景。当前表格的设计可以满足主要的交易需求，但部分场景在未来可能会发生变化。频繁调整表格结构并不利于业务的灵活性和稳定性。因此，为了提高系统的拓展性，新增了一个名为“meta”的JSON结构字段，用于存储自定义信息。通过这种方式，当出现特殊字段需求时，可以灵活地记录这些信息，相当于引入了一个动态的字典表，提升了系统对多变场景的适应能力。
9、宫论寄售藏品表字段结构如下：id、user_id、order、type、status、time、cat、apply、expected_price、auditor、remake、time_summary、auction、staff、identify、official_identify、official_address、express、payment、transaction_amount、settlement、transaction_income、commission、meta。目前一共24个字段，每隔字段都有对应的业务关联。该表因此非常复杂。整个流程跑通了，也就代表核心的拍卖交易也算完成
10、考虑到寄售回收除了正常渠道申请，还可能通过交易商品（拍卖、淘货）、鉴定报告、私藏馆等渠道一键发起申请。对于这种申请，需要再订单交易完成后，做业务回调处理。因此增加两个额外字段apply_type（申请来源）默认情况下是defalut，如果是其它来源则写对应的参数，比如鉴定：identify。apply_order：默认情况下为空，如果是其它场景申请则该值为对应的订单号。注：只有寄售表被取消或完成的状态，才会触发场景业务回调。
11、寄售回收表已通过dbDelta语句完成建立。字段都采用具备索引的类型来生成，主要字段结构类型有如下：时间类型的字段采用（datetime）来构建、涉及到用户参数的字段采用 int(11)来构建，包括主键值、涉及到数组字典的类型，比如时间汇总meta字段则采用json结构构建、其它的常规字段则通过VARCHAR处理，然后根据实际的字段长度来定义。数据表以ID作为主键，并将其设定为递增值。

2024年12月30日
1、新增了数据表：xc_Consignment（宫论寄售藏品表）。该表专门用于处理寄售藏品及回收藏品的业务流程。由于寄售回收业务的复杂性，需要应对涉及交易拍卖、订单回款等多个环节的操作，这使得该表的设计较为复杂。在业务发展过程中，为了更好地适应不断变化的需求和优化处理流程，将对字段结构进行及时更新和调整。
2、寄售表的初始化字段如下：首先是ID字段，它作为主键参数值，以递增的方式写入，用于唯一标识每一条记录。接着是user_id字段，该字段存储申请寄售回收的用户的UID，确保能够准确追踪到具体用户。order字段则代表寄售回收的交易订单号，这个值必须是唯一的，以便在处理交易时不出现混淆。第四个字段是type，它表示交易的类型，目前基本为固定值，用于明确区分寄售和回收这两种模式，因为它们在流程上有许多差异。紧随其后的是status字段，它表示订单状态，这个参数至关重要，因为它直接决定了交易订单的后续走向。接下来是time字段，记录的是用户申请交易的时间，即订单的创建时间，便于追溯订单的历史。最后一个字段是cat，代表藏品分类，用户需自行选择适合的藏品类别，以便在管理和分类时更加准确。
3、在寄售表中新增一个JSON字段：Apply（寄售回收藏品）。这个字段采用JSON格式记录用户的提交信息，以提高数据管理的灵活性和可扩展性。主要包含以下几个关键键值对：photo（寄售藏品图片，这是一个必填项）、video（寄售藏品的实拍视频，虽然目前不是必填项，但未来可能视情况而定）、describe（藏品的描述信息，这也是一个必需项）、time（记录提交申请的时间信息）。通过采用JSON结构，能够有效减少字段冗余，同时便于未来的功能扩展和数据管理。
4、新增了一个名为【expected_price】的价格字段用于设定期望售价。无论用户是申请寄售还是回收藏品，这个期望售价字段都将在申请表单中显示，供用户填写一个他们认为合理的预估底价。该价格将作为保底价被写入数据表中，并且根据实际业务变化来决定是否对藏品实施保护措施。在寄售情况下，这个字段的展示与否将由后台参数控制，属于选择性开放功能。
5、为优化寄售回收流程，提升订单处理的透明度与效率，新增了两个关键字段：工作人员审核字段【auditor】和备注字段【remake】。审核字段用于记录并存档审核员的信息，以便于追溯和管理。备注字段则用于记录订单审核过程中产生的重要信息。尤其是在订单被官方拒绝的情况下，审核员需详细填写拒绝原因，并将其记录在备注字段中。后续的处理步骤将基于订单的状态（status）、审核员信息（auditor）及备注内容（remake）对申请驳回进行管理和处理，以确保每一个订单的决策过程清晰可见，便于后续跟踪与分析。
6、在寄售回收的订单处理中，状态变更的记录细节繁多，例如审核时间、发货时间、寄售时间、上拍时间、成交时间、结算时间、完成时间等多个阶段的时间节点。如果继续采用传统的方式，为每个时间节点单独创建字段，会导致数据表的字段激增，带来过大的存储开销，并严重影响数据库的查询性能。为了优化时间管理和调度，我们决定新增一个字段【time summary】用以汇总记录各个订单状态变化的时间点。值得注意的是，创建时间（time）作为独立的信息，仍将被单独记录，并不包含在这个【time summary】字段中。通过这一策略，我们力求实现数据存储的精简，同时确保系统在处理订单状态变更时能保持高效的性能表现。
7、为了更好地管理和追踪寄售回收过程中拍卖物品的流转，系统在寄售回收表中新增了一个保真阁单号的存储字段【auction：拍卖的交易订单号】。这个字段用于记录每次物品上拍时由系统分配的交易订单号。在拍卖过程中，如果出现交易失败的情况，比如流拍或订单被取消，物品需要重新上架，此时原拍卖单号会被重置为新的订单号。而一旦交易最终成功完成，该交易订单号将成为成交后的固定参数，用于后续的记录和查询。在整个上拍过程中，系统通过这个auction字段来实时追踪和管理拍卖的每一个环节，确保能够准确地掌握拍卖动向。
8、一旦寄售回收的藏品寄出后，需由官方工作人员跟进整个流程，包括签收、鉴定和送拍工作。考虑到这项工作的灵活性，不同的分类可能由不同的工作人员负责跟单，因此会通过后台进行人员配置。为提升管理效率，在数据表中新增一个字段【staff】，用于记录操作员的UID。这样做能够在订单发生变化时，及时通知相关操作员，使他们能够进行相应的操作和处理。
9、寄售回的收藏品提交渠道多样，其中之一是提交鉴定报告。如果收藏品本身附有鉴定报告，那么在官方进行藏品送审时，将有丰富的参考资料。因此，需要使用【identify】字段来存储鉴定报告的ID主键。当官方进行申请审核时，会检测此字段是否存在，若存在，则会在页面展示藏品的鉴定报告结论，以便评定该藏品是否具备送拍的价值。
10、在藏品送审前，除了核查是否具备鉴定报告之外，一旦藏品抵达官方线下评估。如果经验证具备拍卖价值，官方将会出具一份平台认证的线下鉴定报告。这份官方鉴定报告旨在深入评估实物的细节。过程中，会对藏品重新进行拍摄和录像记录，并将其标记为线下官方鉴定报告。此外，寄售回收记录中会使用official_identify字段来记录对应鉴定报告的主键ID，以确保信息的准确追溯和管理。
11、一旦用户的寄售回收申请获得批准，申请者需要将藏品寄送至官方指定的地址。这一地址由后台进行配置，并与审核员参数一起设定。在通过鉴定审核后，收货人的姓名、电话号码和地址等信息将以JSON格式存储在数据表的【official_address】字段中。用户在寄返页面上会调用该参数字段，以完成快递寄送流程。

2024年12月27日
1、修复并解决执行xc_publish_post('consignment')请求时候，返回错误500（ require_once(): https:// wrapper is disabled in the server configuration by）的错误信息，具体错误为服务器是禁止使用 URL 作为 require_once 或 include 的参数，这是为了系统安全考虑。而在执行组件引用处理的时候，错误的使用。链接短代码进行引入，导致一系列的错误。正确的处理，通过xc_local_link方法进行处理。
2、在藏品寄售页面新增了一个必须勾选的藏品寄售协议，以确保用户在进行下一步操作前清楚了解并同意相关条款。协议默认设定为未勾选状态，用户需要主动选择同意后才能继续。协议内容的实现使用了do_shortcode('[xc_protocol type="consignment"]')短代码，这样的机制使得协议内容可以在短代码生成处统一调整和更新，确保所有页面的协议信息保持一致，提高了维护效率和用户体验。
3、在前端打开 publish_consignment 页面时，将自动触发一个访问监听事件。该事件由 myApp.onPageBeforeInit 方法进行处理，无论用户通过何种途径进入寄售藏品申请页面，这个监听事件都会被激活。此外，与寄售藏品相关的任何页面交互行为也都会通过此监听器进行捕获、执行和处理。确保页面上的任何操作都能被及时侦测到，并作出相应的响应。
4、针对寄售藏品分类无法点击切换的问题，已进行了修复和解决。问题的根源在于publish_component_category元素加载完成后，没有正确添加click事件。为了解决这一问题，采取了以下措施：确保在页面加载完成以及分类组件初始化后，对该元素区域进行点击事件监听。具体操作是，用户点击分类后，移除所有兄弟元素的"on"类，并为当前被点击的元素添加"on"类。通过这种方法，成功实现了菜单的切换功能。
5、考虑到后续的维护问题，优化分类监听器的处理逻辑。现在是每个页面都要主动新增藏品分类监听器，要不然所处的页面就无法实现藏品分类的点击切换功能，这样非常麻烦不便，因此做一个全局监听器，访问页面的时候，自动检测页面是否存在publish_component_categor元素，如果存在该元素 说明页面已经完成了初始化分类菜单。此时自动通过click施加菜单点击监听行为处理。这里只要集成了分类组件的模块，就自动支持带单切换。
6、后台新增了一个名为【component.php】的配置页面，专门用于寄售回收流程中全新的参数配置。随着寄售回收流程的更新，系统在配置方面进行了显著的调整，因此原有的配置页面现已弃用。但为了确保系统的兼容性，仍暂时保留旧参数的操作功能。新的配置页面将所有参数以统一的前缀命名，即xc_component_加上具体的参数信息，进一步提升了参数管理的规范性和一致性。
7、关于寄售和回收模块的规划处理，这两个模块在功能和组件上具有极高的相似性，整体的交易流程基本一致。为了便于后续的维护和更新，这两个模块将采取统一的方案进行部署，即共用一个数据表，且大部分配置参数也将保持一致。区别主要体现在最后的交易结算过程和发布申请阶段，其他交互流程基本上是互通的。这可以理解为：在寄售和回收的整个流程中，只有账单结算部分存在显著差异，其他环节则大体相同。
8、在component寄售配置页面，有两个独立的专栏设置，以确保参数配置的清晰与高效。【寄售配置区域】：此区域专注于寄售藏品的系统参数信息配置。在这里，采用了“xc_component”作为前缀来命名参数字段，明确标识其用途。【回收配置区域】：这个区域则负责回收藏品的系统参数信息配置，参数字段命名前缀使用“xc_recycling”。这种设计的目的在于避免两个不同模块的参数混淆，从而确保后期系统维护的简洁与可靠性。
9、寄售模块的配置中新增了一个自定义字段：xc_consignment_publish_header，该字段用于在寄售藏品发布页面的顶部展示自定义信息。字段采用htmlmixed类型，即支持超大文本框输入，方便用户在此处填写详细的寄售规格和说明介绍。在用户发布寄售藏品时，这些信息将直接展示出来，提升用户体验。该字段的设置为参数化设计，便于后期灵活调整和修改。特别指出的是，这个字段支持HTML代码，并与宫论已有的短代码系统无缝集成，进一步扩展了信息展示的多样性和适应性。
10、寄售发布页面（publish_consignment）的正文容器区域（page-content）现已通过调用do_shortcode(xc_get_option('xc_consignment_publish_header'))功能展示后台预设的自定义头部信息。这一功能通常用于显示寄售规则介绍、要求说明等内容，具体信息需要根据实际需求进行填写。由于该功能使用do_shortcode处理，因此全面支持HTML和短代码，为日后的功能扩展提供了方便。例如，可以利用该功能实现页面跳转到详情页等高级操作。
11、在寄售藏品页面新增了期望售价输入框，此功能帮助用户设定一个合理的最低售价。寄售藏品是指将个人收藏寄送给平台，由平台代为出售。期望售价通常被视为最低接受价格，为确保高价值藏品不被低价出售，系统可能通过机器人或价格保护机制来管理交易。如果最终成交价格低于用户设定的期望售价，交易将不会完成，确保了卖家的利益。值得注意的是，心理预期价格即为平台所保证的最低成交价（不包括佣金）。若用户设定的售价过高，平台可能不会接受寄售请求，因此建议用户设定一个合理的价格，以提高寄售的成功率。

2024年12月26日
1、新增的服务号【寄售回收】助理的功能已上线，站内UID为36。在寄售回收交易过程中产生的所有通知，都将通过该服务号以站内信等形式发送。这个服务号的唯一标识为（consignment），不具备消息发送功能。请注意，为了业务流程的统一性，寄售和回收将采用同一套处理方案，这样不仅可以提高效率，也便于后期的调整和优化。不仅仅局限于通知方面，这一调整旨在为用户提供更流畅的服务体验。
2、在构建藏品寄售申请页面（publish_consignment）的过程中，采用了宫论的新标准来设计和构造页面。页面标识使用动态的page_name来命名，该变量在整个页面中起到了核心控制作用，可以优化页面元素的管理，因为它是一个独一无二的值。与此相辅相成，page-content的组织方式采用了【xc_app <?php echo $page_name; ?>_content】的格式，这种设计确保了前端开发可以精准定位和处理每一个页面元素，提高了页面渲染的效率和可维护性。
3、在使用GET请求提取【type：发布来源、order：来源单号】时，如果没有传递这些参数，将使用三元运算符将其设定为空字符。这种处理方式能够有效避免因变量缺失而导致的报错情况。需要特别强调的是，藏品寄售页面已经实现了对来源处理的支持，比如可以通过鉴定订单一键发布、私藏馆一键发布及拍卖订单页面一键发布等功能。由于支持一键发布功能，因此发布来源的设置也显得尤为重要，这确保了后续的功能扩展有一个坚实的基础。
4、在发布页面的page-content容器中，新增了三个自定义属性，分别为：page_name、type和order。这里的page_name用于标识页面的唯一身份，确保每个页面都有一个独特的识别符；type属性则指示发布的来源，使系统能够追踪信息的渠道；order表示来源的单号，这个属性用于记录和追踪发布项目的编号。这些自定义属性将在前端与用户进行交互时发挥重要作用。当用户提交寄售请求时，系统会读取这些属性，再将其整合到发布数组中，统一提交至服务端进行后续的业务处理。
5、在快速构建发布页面的藏品分类展示选择器方法（xc_category_html）中，现已实现对consignment寄售藏品分类的支持。当该方法接收到的key标识为【consignment】时，将从xc_category_config配置中提取寄售功能的开启状态，以及相关启用的栏目信息。随后，这些信息会被整合到一个category数组中。在接下来的for循环中，会遍历数组，构建一个CAT分类展示列表，从而确保所有寄售相关的分类信息都可以被清晰展示和使用。
6、在寄售发布申请页面中，首先展示的部分是一个名为【藏品分类】的box容器。此容器通过调用函数 xc_category_html('consignment')，动态获取并展示所有支持寄售的藏品分类。用户在这一部分需要选择他们希望寄售的具体藏品类别。值得注意的是，在一键发布模式中，系统将自动确定并锁定相应的藏品分类，用户将无法进行修改。而在默认申请的情况下，用户则需手动选择合适的分类，以确保申请的准确性和完整性。
7、图片上传组件构造方法【xc_upload_image_html】现已支持集成寄售藏品功能。只需将传递参数中的KEY修改为consignment，系统就会自动读取之前在后台预设的图片参数信息，并转换为标准的图片上传组件。这一功能将在当前页面中展示，显示的容器为【上传藏品图片】。通过该自动集成组件，用户可以实现一键部署与高效处理。
8、同样的插入和修改图片的组件（xc_upload_image_html_update）已经成功集成至寄售藏品的发布页面。通过其他渠道一键发布的藏品，能够自动导入相关的图片列表信息。这意味着原有订单的图片列表会自动插入到图片容器中，用户还可以根据需要删除或新增图片。尽管如此，图片列表的数量仍然会受到后台设置的限制。由于寄售发布的使用场景相对特殊，因此对该插入功能的需求尤为重要。
9、xc_upload_video_html视频上传组件构造器现已支持【consignment】功能。该方法可自动读取后台的上传配置信息，并生成相应的视频上传组件。当用户发布寄售藏品请求时，可以自由选择是否上传视频。如果选择上传，用户将通过系统生成的组件发起上传操作。上传所需的参数信息由后台的具体视频场景配置决定，确保灵活性和适应性，并且可以根据实际需求随时进行调整。
10、后台文本发布框表单配置（xc_publish_textarea_config），新增一个文本框配置【consignment：寄售文本框】用户发布藏品寄售时插入的文本框。最大文字数字500字，最小文字数量30字。placeholder默认提示文字：藏品介绍补充，比如购买途径、寄售要求。
11、在藏品寄售页面中，长文本框组件的构造方法【xc_publish_textarea_html】现已支持处理寄售品的功能。该组件能够自动读取后台的参数配置，并在页面中对应构建展示内容。此外，这个文本框组件支持实时监听输入的字数，如果字数过长会自动截断，而字数过短则会在提交时提示错误信息。需要注意的是，寄售的藏品需要补充描述说明，以便官方审核员更好地了解藏品的来源和价值，从而判断其是否具备寄售的条件。

2024年12月25日
1、后台内容发布配置字段；xc_publish_link，新增一个发布场景（consignment），专门用于寄售藏品的发布场景。此场景的特定流程为：用户首先提交藏品寄售请求，详细填写藏品的基础信息以及寄售的具体要求（如价格定位）。平台将在接到申请后进行严格的审核处理，只有审核通过的藏品方可被允许寄出至官方以进行寄售。当交易完成后，平台将根据相关规定抽取一定比例的高额佣金，并在扣除平台费用后，结算支付给鉴定人。
2、在宫论用户协议配置字段组中新增了一个协议条目【藏品寄售回协议】，其唯一标识为“consignment”。目前，该协议的具体内容尚未确定，因此链接地址暂时留空，待协议正式确定后再补充完善。在用户进行藏品寄售的过程中，最后提交审核时，需要特别注意要求用户勾选该协议。协议内容将包括关于藏品费用结算、藏品破损处理等详细规定，用户在提交寄售请求之前，必须同意并接受这些条款。
3、新增了一个发布页面，页面路径为【/global/publish/consignment.php】，其独特的标识为：publish_consignment。在前端，用户可以通过函数xc_publish_post('consignment')来进行访问；而在后端，则是借助do_shortcode短代码请求【[xc_link type=global]/publish/consignment.php】来进入页面。需要注意的是，该页面作为统一的发布入口，一般情况下只能通过前端事件来处理访问请求。
4、在藏品寄售页面开发中，已经实现了支持AJAX访问的请求拦截功能。当用户访问此页面时，系统会通过xc_local_link加载ajax_page.php脚本库，以便进行动态内容的处理。为了确保页面的安全性和良好的用户体验，系统会对非法或恶意请求进行实时拦截，识别到疑似机器人的行为时，会要求进行人机交互验证以确认请求的合法性。这种通用的拦截机制不是在页面访问时触发，而是在发布流程中被激活，确保在不影响正常用户访问的同时，高效防止不当请求的发生。
5、在publish_consignment系统中，全面集成了一套完整的组件模块，确保寄售过程中几乎所有的表单操作均通过组件化的方式予以处理。这项集成工作引用了多种功能强大的组件，包括但不限于以下几种：用于图片上传的xc_publish_component_image组件、支持视频上传的xc_publish_component_video组件、供藏品分类选择的xc_publish_component_category组件，以及用于大文本框填写的xc_publish_component_textarea组件。这种模块化和组件化的设计思路将在今后的发布模块中持续应用。
6、随着系统集成的组件数量不断增加，以往每次新增组件都需要手动更新每个发布页面，这给维护工作带来了极大的不便。为了解决这个问题，新增了一个统一的组件模块调度页面【publish_module.php】。所有的组件都将集成到这个调度页面内，当有新的模块组件需要添加时，也只需在这个页面进行更新。其他发布页面只需要通过require_once加载这个调度页面，即可实现对所有组件的引用。这大大简化了维护流程，提高了系统的扩展性和管理效率。
7、此前开发的多个发布页面，包括朋友圈内容、鉴定报告、信息举报以及专家入驻等，现已通过使用require_once do_shortcode('[xc_link type=global]/publish/publish_module.php')的方法，一键集成了发布组件模块。这种做法大大简化了后续的维护工作，为发布页面的管理带来了便利。未来新增的发布页面也将全面采用这一标准，以确保各个组件模块的处理更加规范统一。
8、在用户访问藏品寄售页面时，系统会通过xc_category_config配置读取宫论藏品的分类信息，然后进行遍历处理。在每个分类项中，系统会检查两个开关参数：【open：全局开关，如果关闭，该分类将被过滤】和【consignment：寄售开关选项，如果关闭，则不允许进行寄售操作】。只有同时打开的分类才会被允许进入寄售流程。随后，系统将符合这些条件的分类存储到consignment_cat数组中，以便用于后续页面的构建和交互。
9、在图片上传配置组中，新增了一个场景，专门用于【寄售】用户申请藏品寄售时提交的藏品图片。上传标识设定为“consignment”，自定义样式暂时为空。为了适应未来可能增加的多种上传渠道，图片上传数量上限设定为20张，以确保其他渠道的图片也能顺利接入。上传的最低限制为3张，申请藏品寄售时，系统会验证上传的图片数量，若低于3张则禁止提交申请。图片的最大尺寸暂定为3MB。
10、在同一视频上传配置组中，新增了一个针对寄售场景的功能。用户在提交藏品寄售申请时，现可选择是否上传藏品的实拍视频。目前，这一上传视频的选项是非强制性的，但未来若有需求，可能会考虑增加强制上传的机制灵活改动。如果用户决定上传视频，系统将通过名为consignment的视频配置进行处理，该场景下的视频大小限制暂定为200MB。
11、寄售藏品申请页面，增加GET方式传递两个可选参数的功能：首先是“type”参数，用于标识寄售请求的来源渠道，例如，当寄售请求是通过鉴定订单页面发起时，此参数为“identify”。如果请求来源于其他渠道，则其值为相应渠道的标识符。其次是“id”参数，表示与特定渠道相关的订单主键，这两个参数结合使用可用于精确定位寄售请求的来源。需要注意的是，这两个GET参数并非必填项，未提供时系统默认按标准方式处理寄售申请；若提供了参数，则系统会根据“type”和“id”进行合法性验证，以确保请求的准确性和安全性。

2024年12月24日
1、在「鉴定订单详情页」的功能设计中，已经增设了通过xc_query_settlement的查询机制来确认订单是否已进行过账单结算。当确认订单已结算，并且操作用户为鉴定师时，系统将自动在页面中提取和展示相应的结算记录。此记录详细包括从数据库中获取的settlement结算信息，并将其中的amount参数作为该订单的收入显示在页面的header_info容器底部。此项设计使得鉴定师能够方便快捷地查看自己的账单收入。
2、在status_info容器中，当状态为1（待鉴定）且订单来访者为买家时，系统会通过xc_empty发起文字提示：“藏品等待鉴定期间，您可以选择取消订单。”此前该提示是通过div容器生成的标签来展示的，但该方式在视觉上与页面其他元素不协调，且美观度不佳。考虑到这些问题，目前已改为采用默认的提示方法，以确保界面的整洁性和一致性。
3、当鉴定订单状态显示为（$identify['status'] == 3），这意味着订单因为未在规定时间内得到处理而被系统自动退回。对于不同用户的信息提示作出适应性调整：如果操作者是鉴定师，系统将在status_info容器中显示消息【因为超时未进行鉴定，订单已被系统退回处理】；而当访问者是普通用户时，则会提示【鉴定订单因为鉴定师超时未处理，被退回处理。本次鉴定费已原路退回支付账户】，以确保各方明确当前订单状态及后续处理方式。
4、为了便于后续的维护和处理，订单详情页中的“status_info”容器现已增加身份验证功能。系统将通过“applicant”字段来检查当前用户是否为申请人，若是，则返回true；若不是，则返回false。同理，系统也将通过“expert”字段来判断当前访问者是否为鉴定师，若是，则返回true，反之，则返回false。此外，系统在显示状态提示信息时，会根据用户的身份展示相应的内容，以确保信息的准确性和相关性。
5、当访问的鉴定订单状态为被鉴定师退回处理（即$identify['status'] == 4）时，页面的status_info容器区域将通过xc_empty显示提示信息【订单已被鉴定师退回】。此提示适用于所有用户，无论是鉴定师还是鉴定人。需要注意的是，当藏品存在问题，如资料不完整或分类错误时，系统允许鉴定师对藏品进行退回处理。
6、当鉴定师主动进行退回操作时，系统会记录并储存退回的时间和退回的原因。这些信息将不仅被存储在meta字段中，还会以JSON格式写入return结构的“time”和“reason”字段。当鉴定订单详情页status_info需要输出错误提示时，系统会从meta字段中提取这两个参数，便于在页面上展示“退回时间”和“退回原因”这两个字段，确保用户能够清晰地查看退回详情。
7、在用户提交藏品鉴定请求后，若在鉴定师尚未开始鉴定之前，用户可以取消该鉴定订单。一旦取消成功，订单状态将被标记为5。在鉴定订单详情页面，若订单是由用户自行取消的，会通过xc_empty显示提示信息【用户已主动取消鉴定】。这样不仅可以告知鉴定师和用户订单的当前状态，还能明确说明订单关闭的原因。需要注意的是，在这种状态下，鉴定师和用户看到的信息会保持一致。
8、当鉴定人访问订单详情页时，如果订单状态被标记为（3：超时关闭、4：已退回、5：已取消），这表示订单已启动退款流程。在这种情况下，将新增一个名为 "refund_box" 的容器，用于展示相关的退款信息。这个容器将详细列出退款时间、退款金额和退款订单号等重要细节，以方便用户进行账目核对。需要特别注意的是，由于涉及到订单号的详细信息展示，该功能仅对鉴定人开放。
9、当藏品鉴定订单完成鉴定后，订单状态将被标记为已完成（即$identify['status']=2）。无论是用户还是鉴定师在访问订单详情页时，系统都会通过xc_empty方法在status_info容器中显示【鉴定订单已完成】的提示信息。此提示为通用信息，不区分用户和鉴定师的身份。
10、截至目前，藏品鉴定订单的常规状态处理已全部完成，包括业务逻辑的封装和业务交互过程。剩余的送拍、送审、上架等状态需要与其他模块的订单状态进行关联，后续需进行接入处理。目前，藏品鉴定订单共有五种状态，分别为：1、待鉴定，2、已完成，3、超时关闭，4、鉴定退回，5、用户取消。不同状态的处理方式各不相同，其中涉及订单退款的操作占据了相当大的比例。
11、在宫论藏品分类配置中的xc_category_config中，新增了两个重要选项：一是“寄售”（consignment），此选项开启后，分类下的藏品将支持寄售操作。具体来说，藏品可通过宫论官方平台进行线上售卖，交易成功后平台将收取一定比例的手续费并进行结算。二是“官方回收”（Official_recycling），此选项开启后，该类藏品将支持由官方进行回收。用户可以在线提交藏品进行报价，一旦价格获得官方认可，藏品将被回收，交易完成后相应款项将进行结算。这些新功能的添加旨在提升用户体验及交易的灵活性。