Woo Guard — 结账和资金参考目录两种结账两套钩子表面服务端验证购物车和会话上下文防护资金处理网关和 webhook 回调两种结账两套钩子表面现代店铺运行 Blocks 结账Store API旧版店铺运行短代码结账woocommerce_checkout_*钩子、wp_ajax片段。钩子表面不重叠仅旧版woocommerce_checkout_fields、woocommerce_checkout_process、woocommerce_after_order_notes。BlocksStore API 扩展ExtendSchema、附加字段 API、服务端端点验证。声称通用兼容的扩展要么同时接入两者要么声明它支持哪一个参见 hpos-and-crud.md 中的兼容性声明。AI 生成的结账代码绝大多数只针对旧版表面——在 Blocks 店铺上它根本不会运行钩子挂在错误的表面上会静默失败没有错误没有行为。服务端验证/** * 当 VAT 号码格式错误时拒绝结账。 * * 字段上的 JS 验证是 UX这个钩子才是真正的门禁。 */add_action(woocommerce_checkout_process,function(){$vatisset($_POST[ncs_vat])?sanitize_text_field(wp_unslash($_POST[ncs_vat])):;if(!$vat!ncs_vat_is_valid($vat)){wc_add_notice(__(Please enter a valid VAT number.,ncs-checkout),error);}});对于 Blocks等价物位于 Store API 附加字段/扩展模式回调中。无论哪种方式由服务端决定每个字段都先用类型正确的函数 unslash 再净化错误消息通过wc_add_notice()/模式错误传递——绝不用die()。购物车和会话上下文防护WC()-cart、WC()-session和WC()-customer是为前端请求初始化的——它们在 REST、cron、CLI、webhook 和大多数管理请求中为 nullif(function_exists(WC)WC()-cartinstanceofWC_Cart){$countWC()-cart-get_cart_contents_count();}在 API 回调或计划任务中接触购物车的代码是一个穿着演示店铺外衣的致命错误。即使本地能跑也要在审查中标记它。资金处理存储和算术输入wc_format_decimal( $value )— 规范化本地化小数和精度。显示wc_price( $amount )— 货币符号、位置、分隔符全部来自店铺设置。硬编码的$ . $amount在另外 150 种货币上失效。总额和税费使用订单/购物车 getterget_total()、get_subtotal()、WC_Tax方法——它们应用店铺的舍入模式。用裸浮点数学重新推导总额会产生会计师会发现的几分钱漂移。比较比较格式化后的小数或整数最小单位绝不在浮点上用。退款/折扣逻辑负金额有意义——显式测试零值和部分退款情况test-guard 表示同意。网关和 webhook 回调在触及任何订单之前验证 webhook 签名/密钥以服务商预期的状态码关闭失败。通过wc_get_orders( array( transaction_id … ) )或存储的 CRUD 元数据从网关引用查找订单——不要用自定义 SQL。回调按设计在未认证状态下运行能力检查不适用签名验证就是认证而且每个输入在使用前仍然要 unslash 和净化。幂等性服务商会重试。处理同一个支付事件两次绝不能两次完成同一个订单。
