name: “woo-guard”description: “Review generated or changed WooCommerce extensions, payment and shipping integrations, checkout customizations, and order or product logic.”risk: “critical”source: “community”source_repo: “amElnagdy/guard-skills”source_type: “community”date_added: 2026-07-13author: “community”tags: []tools: []Woo Guard你正在审查生成或更改过的 WooCommerce 代码确保其在发布前合格。在第一次实现之后将以下规则作为守护一遍来应用。WooCommerce 是一个不断变化的平台——订单存储换了引擎、结账换了框架——凭记忆编写的代码针对的是三年前的 WooCommerce。资金攸关在我的演示店铺上能用不是标准。这些规则之所以存在是因为 AI 代理生成的 WooCommerce 代码存在系统性的失败通过get_post_meta()读取订单元数据在 HPOS 店铺上失效、跳过查找表和钩子而直接写 meta 来更新产品、只在 JavaScript 中验证结账、用浮点数计算价格以及在确认 WooCommerce 已激活之前就注册woocommerce_*钩子。何时使用在审查生成或更改过的 WooCommerce 代码——扩展、支付和配送集成、结账定制、订单/产品逻辑——并准备发布时使用此技能。在代理编写或修改了 WooCommerce 钩子、HPOS 逻辑或结账流程之后以反应方式激活它。如何使用此技能守护模式推荐在 WooCommerce 代码被生成或编辑之后对 diff 或目标文件应用规则然后在交付前运行自检。实时模式显式当用户在编写 WooCommerce 代码之前调用此技能时在编写时应用相同规则然后在交付前运行自检。审查模式用户要求你审查或审计 WooCommerce 代码浏览 references/review-checklist.md 并生成结构化的发现报告。除非被要求审查模式下不要编辑代码。安全底线— 以下要求在所有 WooCommerce 代码中都成立并以最高严重性执行因为资金攸关使用与上下文匹配的esc_*函数转义所有输出。所有请求数据在触及逻辑之前先wp_unslash()再净化。每个状态变更都有能力检查加 nonce。每个包含变量的查询都使用$wpdb-prepare()。如果安装了 wp-guard请与它并行运行以覆盖完整的 WordPress 层。先适配项目阅读项目的代理指令和扩展声明的 WooCommerce 版本范围。项目约定冲突时以项目为准。确定此代码必须支持的订单存储模式HPOS、旧版 posts或两者默认假设为两者。确定涉及的结账方式Blocks/Store API、旧版短代码结账或两者。一方的钩子在另一方中不会触发。检查 WooCommerce 活动是否有防护在任何wc_*调用或woocommerce_*钩子之前有功能检查或class_exists( WooCommerce )。规则订单和产品数据 — 必须修复订单不是 post。只能通过 CRUD API 访问订单wc_get_order()、wc_get_orders()、$order-get_meta()、$order-update_meta_data()$order-save()。对订单数据禁止get_post_meta()、update_post_meta()、带post_type shop_order的WP_Query/get_posts()以及对 postmeta 的直接$wpdb连接。这些在旧版店铺上有效但在 HPOS 店铺上会静默失效。详情references/hpos-and-crud.md。CRUD 对象、getter/setter然后 save。产品、客户和优惠券通过其 CRUD 对象wc_get_product()、setter、-save()操作。直接写 meta 会跳过查找表同步、跳过其他扩展依赖的钩子并跳过缓存失效。库存变更走wc_update_product_stock()语义订单状态变更走$order-update_status()——它们会触发店铺期望的邮件和钩子。声明功能兼容性。任何触及订单的扩展都要声明 HPOS 兼容性FeaturesUtil::declare_compatibility( custom_order_tables, … )任何触及结账的扩展都要声明cart_checkout_blocks兼容性或不兼容要诚实。缺失声明会让每个店铺所有者看到一个带有你的插件名称的警告横幅。结账和资金 — 必须修复结账验证在服务端。在woocommerce_checkout_process旧版或通过 Store API 扩展模式Blocks验证。JavaScript 验证只是 UX绝不是安全。要知道店铺运行的是哪种结账当扩展声称通用兼容时要同时接入两者。金钱不是浮点数。价格和总额通过wc_format_decimal()获得存储安全值通过wc_price()显示算术使用 WooCommerce 自己的税费/舍入设置。不要手写货币符号不要对价格使用number_format()不要对总额做浮点相等比较。运行时纪律 — 应当修复防护运行时上下文。WC()-cart和WC()-session在 REST、cron、CLI 和管理上下文中为 null——接触它们之前要检查。绝不要假设 webhook 或网关回调中有已登录的客户。验证每个woocommerce_*钩子和wc_*函数在支持的版本范围内存在——WooCommerce 在主版本之间会重命名和淘汰钩子。钩子优先于模板覆盖。按顺序优先现有的 WooCommerce 钩子/过滤器 →woocommerce_locate_template过滤器 → 主题级覆盖。插件内附带的模板覆盖会把一个复制文件冻结在某个 WooCommerce 版本上并在模板更新时失效——审查时始终标记它。后台工作随订单量扩展。批处理作业、同步和 webhook 分发走 Action Scheduler随 WooCommerce 附带而不是裸的 WP-Cron 循环。处理器必须幂等——真实店铺中订单事件会触发多次。交付前自检在 diff 中搜索get_post_meta、update_post_meta、post_type shop_order其中有触及订单的吗规则 1有没有绕过 CRUD 对象save()的产品/订单/客户写入规则 2扩展是否声明了 HPOS以及相关时的结账 Blocks兼容性规则 3每条结账规则是否都在服务端、针对店铺实际运行的结账方式实施规则 4有没有浮点运算、硬编码货币符号或对资金使用number_format()规则 5有没有可能在 REST/cron/CLI 中运行的WC()-cart/WC()-session访问有没有未经验证的钩子名规则 6插件中有附带模板文件吗规则 7安全底线每个输出都转义了吗每个请求输入都 unslash 后净化了吗每个状态变更都有能力检查并验证 nonce 吗每个含变量的查询都预处理了吗如果任何答案是否在展示给用户之前修复它。报告格式审查模式**规则 N 违规** in path/file.php:line or function - What: 一句话 - Risk: HPOS 失效 / 跳过钩子 / 资金错误 / 结账绕过 — 一个短语 - Fix: 一句话按文件分组以规则 1–5 的发现开头。如果文件干净不要提及。严重性指南必须修复规则 1–5 — 店铺损坏、业务逻辑被跳过、金额错误应当修复规则 6–8 — 上下文崩溃、更新脆弱、规模化时挂掉的作业参考references/hpos-and-crud.md — HPOS 背景、CRUD 模式、兼容性声明、违规表references/checkout-and-money.md — 旧版与 Blocks 结账、Store API 验证、价格和货币处理references/review-checklist.md — 审查模式的结构化流程references/sources.md — WooCommerce 开发者文档 URL仅在引用时阅读此技能不做什么不覆盖安全底线之外的完整 WordPress 层——i18n 和资源/查询纪律在安装了 wp-guard 时属于其管辖范围。不审查店铺配置、主题样式或支付服务商账户设置。不决定定价或业务逻辑——它守护 WooCommerce 代码如何发布而不是店铺卖什么。