2025年4月2日
1、在用户完成发货操作后，服务端会将相应的结果反馈给前端进行处理。前端页面会根据返回的code值进行相应的页面交互操作。如果code值为1，则表示本次发货操作失败，可能由于各种原因被拦截处理。此时，页面会通过msg显示相应的提示信息。如果接收到的结果是code值为0，则表示本次发货操作成功，同样会触发msg提示，但后续还会执行一些方法来进行页面交互处理。除了监听code值外，系统还会对complete状态进行监听处理，以确保在服务器响应异常的情况下，主动触发xc_loading_hide，避免页面始终处于异常状态。
2、新增了名为xc_express_official_hook_callback的回调脚本，当用户成功发出寄售回收藏品后，服务端将会返回code=0。此时，系统不仅会触发页面提示，还会激活这个回调脚本。在回调脚本中，页面将会执行以下一系列简单的交互操作。首先，将特定元素进行页面锁定处理【$('.send_collection_details_content');】。接着，获取页面中的操作按钮，并对其进行一系列调整：清理按钮的onclick事件以防止重复点击，将按钮文字更改为“发货成功”，并将按钮的背景颜色更改为黑色。
3、在规范化管理方面，后续所有前端HOOK事件的执行，如果成功【code=0】，都会主动触发相应的callback脚本事件。所有的页面交互都将通过callback脚本来处理。在回调脚本中，回调参数的命名方式将通过原HOOK名称加上callback后缀进行处理。如果需要接管相应的回调处理，只需检索原HOOK名称即可。需要注意的是，通过callback进行页面交互时，必须主动继承原有的变量参数，以确保能够正确进行相应的页面交互处理。
4、对ajaxSetup全局初始化配置进行了优化调整，新增了以下监听器：【dataFilter：数据处理过滤器】【error：自定义错误处理（覆盖全局错误）】【success：成功回调（需慎重使用，避免出现冲突）】【complete：请求完成后（无论成功与否）】【beforeSend：请求即将发送前】。这些监听器都是在ajax请求发送前后执行的处理动作，通过这些监听器，可以全面接管整个ajax交互过程。前后端的交互行为基本上都是通过ajax来完成的，因此这些监听器显得尤为重要。
5、在ajaxSetup初始化过程中，complete监听器会进行额外处理。首先，它会从xhr对象中提取关键参数【responseJSON】，并将其保存到data中。接着，验证返回值是否包含data，如果包含则进一步检查data是否为对象。如果data存在且为对象，还会进一步核验当前页面是否存在遮盖提示层。这个遮盖层是为了防止用户误点击，在页面交互过程中由系统发起的。如果遮盖层存在，则通过complete监听器进行主动关闭操作，以避免服务端响应结果异常，导致页面始终处于遮掩状态，从而无法进行点击交互。
6、系统通用的ajax配置不仅新增了各种监听器，还对以下参数进行了预设处理。首先，withCredentials被禁用以防止跨域时携带cookie，确保系统的整体安全性。其次，dataType默认配置为json，确保ajax请求能够自动响应并解析json结构。processData参数设为true，系统将自动把对象转换为查询字符串。为了避免前端发出同步请求造成阻塞，async参数强制设为true，确保所有请求都以异步模式进行。timeout参数被设定为10秒，这意味着任何请求超过10秒将会立即返回异常。此外，所有ajax请求的type参数均设置为post，确保所有数据传输都通过post方式进行。
7、宫论的AJAX请求会主动携带以下头部信息：【X-Requested-With: XMLHttpRequest】用于标识这是一个AJAX请求；【X-Content-Type-Options: nosniff】用于防御MIME类型混淆攻击。上述两个请求头通过ajaxSetup进行配置处理，每次发起请求时都会自动添加。此外，为了保证参数的安全性和可靠性，每次请求还会携带一个专属头部【X-gonglun-ajax】，其参数为$.now()生成的当前时间戳。这些头部信息将在后续的拦截器中进行安全校验，以确保请求的安全性和可靠性。
8、在初始化 xc 对象时，新增了一个重要字段：wpApiSettings。这个参数通过调用 wp_create_nonce('wp_rest') 函数生成，该函数利用系统内置的安全密钥（Nonce）来提供以下几个关键功能：首先，防止 CSRF 攻击。Nonce 确保请求来自可信的来源，有效防止恶意第三方网站伪造请求。其次，验证用户权限。在执行敏感操作前，通过验证 Nonce 可以确认用户具有相应的权限，从而确保只有授权用户才能进行这些操作。最后，提升安全性。在 REST API、AJAX 请求、表单提交等场景中使用 Nonce，有助于增强整体网站的安全性。这个参数在初始化时生成，后续将会集成到前后端交互中，确保所有请求的可靠性。
9、宫论每次发起ajax请求时，会主动传递以下参数：1、头部信息【'X-WP-Nonce': xc.wpApiSettings】，这是一个WordPress安全随机数，在页面初始化时会自动生成。2、data数据参数：_wpnonce，每个请求自动携带的校验参数；_wp_http_referer，表示当前页面的URL，用于来源页验证。需要注意的是，核心验证参数为wpApiSettings，这是系统生成的唯一加密请求参数，通过ajax发送到服务器端。服务器在接收到请求后，会对该参数进行解析和验证，以确认其有效性。
10、宫论服务端【API请求拦截器：ajax_api.php】已经完成重构和优化处理。新增了安全校验机制：包括重新设计的Nonce校验（同时验证Header和POST参数），具体对_wpnonce和HTTP_X_WP_NONCE进行核验提交处理。通过wp_verify_nonce读取header和data对象中的wp_rest，如果读取失败则说明本请求的参数与后台生成的密钥不一致，此时系统会直接返回错误信息：“非法请求: 参数错误(-02)”，并立即终止请求，返回JSON格式的错误信息，拒绝后续的接口调用请求。
11、服务端的API拦截器，除了进行Nonce效验检测和拦截处理之外，还会执行Referer验证处理。具体操作是通过wp_get_referer函数获取Referer地址，然后从$_SERVER['HTTP_HOST']中获取当前请求的主机名。验证Referer的有效性和来源。如果请求中没有Referer，或者Referer的主机名与当前主机名不匹配，则认为该请求来源不合法。在核验过程中，不仅要比较Referer的主机名是否与当前主机名相同，还会使用hash_equals()函数在恒定时间内比较两个字符串，以防御时序攻击（Timing Attack），确保系统的安全性和可靠性。

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位。

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

测试看看最低多少钱？

内容测试出