2025年4月1日
1、由于集成了update_time字段，可以显著减少对数据表时间字段的维护工作。每当数据表发生变化时，系统会利用CURRENT_TIMESTAMP机制自动发起更新处理。结合status字段的管理，可以明确了解当前订单所处状态的持续时间，从而有效触发系统任务调度的执行。因此，所有主要的数据表均已手动添加该字段，未来新增的业务数据表也必须整合此字段，以确保数据的一致性和追踪性。
2、在完成xc_consignment数据表的状态回调操作后，系统会立即执行【xc_consignment_status_hook($consignment['id'])】方法。该方法是一个内置的通用刷新机制，每当寄售回收订单数据表中的字段发生更新时，都需要通过执行这个方法来刷新缓存数据。这样做的目的是确保分页查询、审核列表和统一订单查询的缓存能够同步更新，从而保证这些页面返回的数据是真实可靠的。
3、在宫论全局push通知管理中，我们新增了一个消息场景：【寄售回收】订单发货线下验收通知。当用户的寄售回收订单通过线上审核后，如果用户在规定时间内通过线上发货页面完成寄出操作，则会触发此消息通知。此通知将提醒相关审核工作人员立即关注订单的状态变化。如果订单已收到货物，则需及时进行验收，并按照流程进行线下入仓和鉴定处理。该通知场景的唯一标识为：consignment_shipping。
4、为了确保系统安全保护，用户通过xc_express_official_hook钩子寄出藏品时，系统会重新通过xc_category_config配置信息读取当前负责的线下工作人员，并将其地址重新写入到$express_delivery['staff']字段。虽然在提交订单时系统会自动写入线上专家人员的信息，但由于存在一定的延迟，从提交到审核再到寄出藏品，这个过程可能长达十几天甚至更久。如果平台在此期间更换了工作人员，可能会导致交易流程出现不可预估的错误。因此，在发货时进行重新读取，可以大大减少这种问题的...
5、在寄售回收的藏品寄出后，相关工作人员会通过多渠道接收通知，确保信息的及时传达。目前已开启【APP通知、站内信、服务号消息】三个渠道来实现这一目标。当APP处于在线状态时，工作人员会收到即时的站内信弹出窗口通知，确保第一时间获取信息。如果APP处于离线状态，则会通过离线消息推送（push通知）将消息传递给工作人员。此外，无论APP的在线状态如何，宫论服务号都会收到发货消息提醒，确保信息传达的全面性和可靠性。用户也可以通过站内信查看订单的发货记录，便于后续的查询和管理。该消息场景已被标记为“寄售订单通知”，以便于信息的分类和管理。
6、关于consignment_shipping的通知计划共有两个步骤。首先，当用户执行发货操作时，系统会触发一条简单的站内消息，提醒验收工作人员及时关注相关订单。这类消息仅限于站内通知，不涉及短信、邮件或公众号等外部渠道。其次，当用户发货超过5天且订单仍处于待发货状态时，系统将启动一次消息检查流程。此时，会发送一条提醒给工作人员，敦促他们及时跟进订单的处理进度。通常情况下，发货后3天左右订单应已处理完毕，若超过5天仍未处理，则可能存在问题。因此，这类通知会采用更为复杂的方式，包含短信和邮件等多渠道提醒，以确保问题得到及时解决。...
7、在通过xc_notify_hook发送【consignment_shipping】通知消息时，系统会自动封装一个变量【push_data】。这个变量包含了一系列关键参数信息，以确保消息在异步环境下能够正确处理。具体来说，push_data包括以下内容：1、id：这是本次处理的寄售回收订单的主键ID，用于唯一标识和后续处理。2、ip：这是通过调用xc_is_ip函数获取的当前用户的IP地址信息。3、ua：当前用户的用户代理（User Agent）信息，由xc_is_ua函数获取。4、指纹信息：这项信息是通过读取用户的浏览器指纹获得的。之所以需要提前封装并传递这些参数，是因为在大多数情况下，xc_notify_hook是在异步环境中运行，系统无法实时获取当前的环境信息，因此需要在通知发送前就将这些信息准备好并封装在一起。
8、在处理寄售回收的用户发货通知时，系统首先调用统一订单查询方法【xc_query_consignment】以获取当前订单的配置信息。如果查询失败，流程将会立即终止。而一旦成功获取，该信息将被存储到变量consignment中。接下来，系统会利用consignment中的数据逐步读取【xc_category_config】的藏品分类配置信息，特别是提取[express_delivery]字段中发货订单的主键ID。随后，系统通过调用【xc_query_express_delivery】方法获取相关的发货记录信息，并将这些信息存储到express数组中。后续的参数封装将依赖于这些获取到的信息，以确保整个流程的顺利进行。
9、寄售回收订单发货PUSH，关键参数封装处理：1、标题通用变量（APP、邮件、服务号、站内信）：[审核通知]寄售回收发货通知。2、正文通用变量：用户已寄出了“' . $cat_name . '”藏品，请及时跟进处理。（其中，cat_name是通过解析category_config配置参数获取的藏品分类。）3、链接通用变量：用户点击后将直接跳转至审核大厅页面，用户需自行在大厅中前往审核列表页面。请注意：未来将推出订单审核页面，届时点击会调整为跳转至订单详情页了。
10、宫论服务号不仅仅是一个简单的消息通知工具，还具有历史记录溯源的功能。用户可以通过点击服务号查看所有过往的关联通知记录。因此，在设计（寄售发货通知）消息场景时，需要尽可能详细地封装信息。除了标题和正文内容外，还通过菜单方式集成以下内容：第一栏显示'订单号'，后接具体的订单ID；第二栏显示'发货时间'，以当前日期和时间格式化展示；第三栏提供'快递公司'的信息，依据快递公司的配置进行解析；第四栏则是'快递单号'，通过提取发货记录获取。这样设计的目的是确保用户在查看服务号消息时，能够一目了然地获取到所有与订单相关的关键信息。
11、完成了push通知下发处理后，xc_express_official_hook事件便已经完成处理。系统此时会返回code=0、msg='藏品发货成功'。剩下的就是前端进行页面交互处理，服务端的响应便已经结束。整个执行过程如下：1、hook_before拦截响应事件，包括外部拦截参数的处理。2、express_delivery物流发货记录参数的封装处理，数据表写入动作处理。3、通过xc_update_sql发起寄售回收订单状态的回调处理，将订单状态、验收员工、快递记录记录更新处理。4、通过xc_consignment_status_hook进行缓存更新处理。5、触发xc_notify_hook消息通知下发，告知工作人员，订单藏品已寄出。6、hook_afte回调动作脚的响应处理。

2025年3月31日
1、在通过xc_express_official_hook成功完成发货请求后，相关的数据将被写入到数据表xc_express_delivery。接下来，系统将进行订单回调操作。具体而言，系统会通过insert变量来判断xc_insert_sql的返回执行状态。如果返回结果为空，则系统将提示错误信息：发货错误：数据表（express_delivery）写入失败！反之，如果返回结果为false，说明执行成功，系统将封装一个名为consignment_update的空数组。该数组将作为后续更新操作的依据，以确保数据的一致性与准确性。
2、consignment_update数组的封装结构如下：首先，将status字段的值变更为4，这表示用户已经完成了发货请求，并已将藏品寄出且填写了运单号。接下来，读取$consignment['time_summary']中的json字段，并在原有基础上新增一个字段【express】，该字段用于记录当前的发货时间。time_summary是一个时间汇总的json字段，用于记录订单各个时间维度的信息。由于涉及到json的复杂操作处理，这里采用了xc_is_json_update方法进行处理，该方法能够自动解析json并转换为数组，同时也支持自动更新并插入新的数组字段，最终再将其转回为json格式。
3、在完成对update数组的更新处理后，系统将生成一个update_where数组，该数组仅包含一个ID参数值。接着，通过对consignment的调用，我们可以获取到订单数据表的主键ID。在将update和where的参数进行封装后，系统会调用xc_update_sql(table_name,table_name,update_data, $where)来执行更新请求。如果更新操作成功，系统将返回true；若操作失败，则返回false。此外，需要注意的是，通过xc_update_sql更新的数据表会自动触发缓存刷新处理，确保后续查询所返回的结果是可靠且有效的。
4、寄售回收订单数据表（xc_consignment）新增一个字段（update_time）该字段为更新时间。字段采用 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP类型存储。当插入新记录时，如果没有指定update_time的值，会自动填入当前时间。而ON UPDATE CURRENT_TIMESTAMP则是关键，它会在每次更新记录时自动将update_time字段更新为当前时间戳。这里可能需要举例说明，比如当执行UPDATE语句修改其他字段时，这个字段会自动变化。
5、因为订单的复杂性，需要每次订单发生变化的时需要自动更新update_time字段，这样在执行系统任务的时候，task接口可以通过status+update_time来知晓订单状态时间。示例：比如系统任务需要检查用户发货超过5天，还未入仓的寄售订单。对于这类异常订单，需要下发通知给验收工作人员。这个时候可以通过监听status=4，并且update_time超过XX天的记录，然后进行业务处理。这个处理过程非常依赖update_time的自动更新，如果每次都维护这个时间字段，非常的麻烦。最好是系统自动保持更新。‘
6、数据表的规划处理：所有的数据表都增加【update_time】字段，并且都是以UPDATE CURRENT_TIMESTAMP字段类型来自动维护。这样数据表发生变动的时候，系统会自动将对应的时间戳加上。默认情况下，数据表的字段必须包含以下几个字段。1、id（主键值，这里为了兼容性，采用的小写字母）2、time：数据表建立的时间，只有插入的时候才会触发写入。3、status：状态字段。当订单发生变化的时候触发更新处理，通过状态判断订单的类型。4、update_time当订单发生变动系统自动更新的时间。5、可选（type）订单的来源标识，可选，部分数据表不需要。
7、宫论IS脚本库新增了一项检测获取方法，名为xc_is_ua。对于后续的一些业务，如需在服务器端或获取来访者的用户代理（UA）信息，都必须通过该方法发起请求。此方法将在内部通过$_SERVER['HTTP_USER_AGENT']读取浏览器的UA字符串。同时，由于封装层级的问题，可以利用php_sapi_name来验证当前环境是否为命令行，这样能够友好地区分脚本执行和客户执行。此外，该方法还支持接管其他方法，对于APP等特定环境，会通过UA识别进行相应的参数接管和替换，从而实现更高效的返回处理。
8、对xc_is_ip方法进行了重构，以提升系统获取来访者IP地址信息的准确性。传统上，该方法通过$_SERVER['REMOTE_ADDR']来获取IP地址，但未考虑到在代理层下可能存在的情况，导致获取的IP信息不一定真实可靠。重构后的方法会检查常见的HTTP头，以便在出现多层代理的情况下，提取第一个非unknown的有效IP地址。如果成功获取到有效IP，则返回该IP；如果未经过代理，则直接返回REMOTE_ADDR。通过这一系列优化，可以确保系统返回的IP地址始终是可靠且真实的，从而增强系统的安全性和准确性。
9、在通过xc_update_sql完成寄售订单回收操作后，系统将对返回结果进行严格的核验处理。如果操作失败，系统会返回相应的错误信息，并相应地协调后续执行动作以确保问题得到解决。若执行成功，系统将进行订单回调处理，利用Redis清理相关的缓存记录，包括统一订单查询和统一列表订单查询（与当前寄售订单相关的缓存）。这一流程旨在确保未来的订单查询操作均通过wpdb发起，以增强返回内容的可靠性。这项措施有效避免了在发货已完成的情况下，订单查询接口因延迟问题而仍显示处于待发货状态的情况。
10、在完成缓存清理动作后，寄售订单藏品寄出事件便基本宣告结束。此时系统会执行hook_afte脚本，该脚本负责外部事件的回调处理，如果第三方事件需要接收通知，可以通过内置xc_do_action方法来注册函数，注册方法需要按照标准的wp过滤HOOK来进行处理，一旦完成注册，系统在完成寄售回收订单发货处理后，会将对应的ID订单主键转发到注册方法内，具体业务在对应的注册方法中进行执行并响应。
11、xc_consignment新增一个字段：express_delivery（藏品发货记录），当用户提交藏品寄售回收申请的时候，订单会进行线上专家审核，审核通过后。用户需要将藏品寄到官方，在订单详情页完成发货请求后，系统会将发货运输记录写入到【宫论物流跟踪表】，这个时候为了追踪方便，系统会将运输记录ID主键ID值，回调到寄售订单表的[express_delivery]字段，后续物流追踪的处理，都将通过查询这个字段来发起。注：该字段采用INT来存储，因为本身是主键ID，因此必定是数字。长度限定为11位。

2025年3月28日
1、为了提高系统的模块化和重用性，设计了一个专门的HOOK事件，名为xc_express_delivery_add_hook，用于更新wp_xc_express_delivery数据表。这个钩子将接收一个名为express的数组，该数组包含了写入数据表所需的各种字段信息。在构建这个数组时，需要遵循严格的字段标准，虽然部分字段会在内部生成，但大多数字段如订单类型、订单标识、收件人信息、快递单号以及承运公司等都需要从外部传入。重要的是，无论是卖家还是官方发货，都应通过这个HOOK事件来执行数据写入操作，这样可以确保数据的统一性和准确性。
2、系统在通过 xc_express_delivery_add_HOOK 接口更新运输记录时，会返回一个标准的数组结构用于判断处理结果。其中，返回值 code=1 表示写入失败，失败的原因可能包括权限不足、数据表异常、字段结构不符合要求等，具体的错误信息会通过 msg 字段进行传递。所有失败情况统一返回 code=1。若处理成功，则返回 code=0，表示数据库写入已成功完成，当前订单的发货信息也已成功登记。注：在执行业务回调处理前，需要执行收货地址表的更新，如果更新失败需要中断执行，禁止后续的处理。
3、在通过HOOK执行订单发货表的更新处理时，系统会启动以下拦截检测机制以确保操作的安全性与准确性。首先，会检测用户是否已登录；若用户未登录，系统将返回错误信息，并提示用户需要先进行登录，因为在发货过程中，用户在线是不可或缺的，尤其在输入或录入单号的环节。其次，系统会对参数进行效验，检查express数组的结构是否完整，若发现有信息丢失或缺失的情况，将及时返回相应的错误提示。在数据插入表时，系统还会对关键参数进行esc_sql处理，以有效防止SQL注入风险，从而保障系统的安全性。
4、官方收件仓库信息配置组（xc_express_official_config）新增了一个重要字段：user_id（收货员的宫论UID），该字段旨在负责处理一系列发货消息的接收工作。例如，在A仓库（位于上海某地，专门处理玉器寄售）中，一旦设定了收件人UID，当用户或卖家寄出藏品后，系统会自动读取该仓库的站内UID，并及时向相关方发送通知消息。此外，系统在货运列表筛选功能中也将提供通过UID一键查找该仓库收货历史记录的便利。需要注意的是，设定UID并不意味着所有的通知都将通过此UID发送，具体的通知处理方式将依据不同的业务场景而有所区别。
5、为防止重复执行和数据写入，在通过HOOK发起发货处理请求时，系统将利用Redis进行上锁保护，锁定时间为5秒。锁的标识为：express_official:user_id，确保每个用户在同一时间段内只能执行一次请求，重复请求将被系统自动拦截，并返回相应的错误提示，旨在防止用户因不小心多次点击而导致物流信息的重复写入，从而引发后续处理中的异常情况。此外，前端也将设置遮盖层以阻止用户重复点击，但考虑到安全问题，后端的上锁机制倍显必要性，从而提供更为稳妥的防护措施。
6、在封装express_delivery数组的过程中，系统会依次读取一系列配置参数以完成数组的构建处理。首先，通过调用xc_query_consignment接口获取相关的交易订单数组信息。接着，利用xc_is_config接口获取快递公司的配置信息，该信息包括快递名称和快递编号。随后，系统通过xc_category_config接口采集藏品分类的信息，以便于后续的处理。根据订单类型（寄售和回收的配置有所不同），系统会读取xc_express_official_config接口中的官方收件地址配置。最后，依托订单类型，系统将读取相关的线下工作人员信息，并将这些信息保存到staff字段中。
7、express_delivery数组已完成封装，具体结构如下：type（类型标识，例：consignment 表示发货单）。shop_id：订单ID，关联订单表的主键。user_id：发货人ID，可能是商家或系统用户。recipient ：收件人ID，通常是用户UID。name：收件人姓名。phone:收件人手机号. province:收件人所在省份。city：收件人所在城市。county：收件人所在区/县。detailed_address：收件人详细地址（街道、门牌号）。address：收件人完整地址（拼接后的）。courier_company ：快递公司名称。code：快递单号（已使用 esc_sql() 转义）。time：发货时间。created_at：创建时间（通常与发货时间一致）。status：物流状态，0 表示未发货或初始状态。link：跳转链接。express_key：快递公司唯一标识（如拼音缩写、代码等）。
8、xc_express_delivery_add_hook在处理完成基础效验工作后，会直接通过xc_insert_sql($table_name, $data)执行数据表写入动作。并将执行结果保存到$insert变量。如果插入成功则insert是本次插入的行数主键。如果插入失败则会返回false。如果插入失败则返回【错误：数据表执行错误】并返回code=1.如果返回了插入ID，则返回code=0，并且额外返回insert字段。上级业务HOOK钩子，可以通过判断code或者insert来验证是否插入成功。注：xc_insert_sql是系统封装好的方法，支持缓存管理。
9、宫论统一订单查询接口新增了一项方法：xc_query_express_delivery()，该方法可以通过物流数据表的ID来查询相关的物流运输记录。使用此查询方法时，需要传递一个主键变量$id，系统会内部构建一个wpdb查询语句，以便从xc_express_delivery数据表中检索对应的记录。在检索的过程中，为了确保数据安全性，采用prepare函数进行参数过滤，并使用get_row函数来返回单行数据。如果查询结果存在有效内容，则会将其转换为数组格式进行返回；若查询未能找到相应结果，则将返回false。通过这种封装方法实现订单查询，不仅减少了SQL语句的构建复杂度，还有助于后续的维护与管理。
10、物流订单查询方法新增一个缓存控制开关：uncache该值默认为false，即返回优先缓存。如果将其设置为true，则系统会优先检索缓存是否存在，存在的的情况下，则直接返回缓存，而不是从wpdb发起sql查询。这样可以有效的减少数据库的读取，提升整体响应速度。缓存的键名为：$redis_key = "express_delivery:" . $id;。缓存有效期为24小时，超时会自动清理缓存。通过wpdb发起查询的时候，会在返回结果前主动更新缓存结果。
11、为了提升物流查询的灵活性，xc_query_express_delivery统一物流查询方法进行了重要更新。此次更新不仅增强了对ID主键的查询支持，同时也新增了通过code进行查询的功能。系统内部会自动检测传递的ID是否为纯数字，并判断其长度是否小于8位。如果满足这些条件，系统会在wpdb语句的检索中将ID转换为code进行查询。此外，由于ID同时引入了两种查询方式，因此在缓存的更新与写入机制方面进行了相应的调整。在成功读取到查询结果后，系统将同时提取ID和code，并单独执行update_redis_meta操作，以确保两个缓存的同步生效。需要注意的是，这一处理不仅兼顾了ID和code的索引，还实现了缓存的自动同步更新功能，从而进一步提升了查询的效率与准确性。

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

测试看看最低多少钱？

内容测试出