WooCommerce 如何在自己的域名发布 /sku.md
v1.0.0 专题
从 WooCommerce Store API 证据到 WordPress 路由、人工审核、原子发布、监测和回滚的完整流程。
当前状态： 本文依据当前 v1.0.0-beta 边界撰写，只陈述方法和证据要求，不把尚未验证的平台采用、排名、引用、推荐或销售结果写成事实。
WooCommerce 运行在 WordPress 中，因此店主通常比全托管平台拥有更多路由控制权。但只有生成、审核、发布、监测和回滚形成一条可追责流程时，这种控制才真正有价值。
当前状态与证据条件
公开 WooCommerce PoC 尚未标记完成。Store API 和 WordPress 路由 API 提供了实现基础，形成支持结论仍要求一套他人可以验证的公开安装。证据出现前，下面描述的是目标流程，不是已经完成的集成结果。
把商店证据映射成草稿
从受鉴权和范围限制的商店数据源读取商品与变体，只映射含义明确的字段：规范商品 URL、标题、已审核描述、尺寸、属性、变体标识符和来源链接。不能从缺失属性推断限制，也不能把当前库存和价格复制进静态知识。
生成结果必须保留来源。每个输出项都要能追溯到 WooCommerce 字段或编辑来源，发生冲突时交给人工审核。
注册公开 WordPress 路由
插件可以为 /sku.md 注册 rewrite rule 或 REST endpoint，并返回 UTF-8 Markdown 与允许的媒体类型。主题、缓存插件、安全中间件或其他插件都可能拦截同一路径，因此路由所有权必须明确。
只在激活或配置变化确有需要时刷新 rewrite rules。以未登录访问者身份确认路由，并记录重定向、缓存响应头和最终字节。
人工审核必须位于发布之前
编辑应先在暂存状态审核目录和抽样商品文档，重点检查变体身份、无依据陈述、缺失限制、薄弱来源和意外出现的实时商业字段。Parser 能检查语法，却无法判断适用性陈述是否诚实。
校验通过后再原子发布，避免消费者读到半写入文件，并保留上一个有效版本用于回滚。
更新与失效闭环
已审核事实、标识符或来源页面改变时生成新草稿。库存和价格事件不应触发 SKU.md 重建，因为它们不属于知识边界。持续监测公开路由、Validator 结果、来源可达性和上次批准时间。
如果新草稿校验失败，继续提供上一个有效版本，并把失败草稿交给编辑。删除商品时先更新目录，再有计划地退役对应文档。
PoC 验收记录
| 阶段 | 必须保留的证据 |
|---|---|
| 映射 | 输入字段、输出陈述、来源关系 |
| 审核 | 审核者、修改和未决问题 |
| 发布 | 公开 URL、状态、响应头、内容哈希 |
| 校验 | 工具版本与结果 |
| 更新 | 触发原因和替换时间 |
| 回滚 | 恢复版本与原因 |
证据条件
只有插件流程在公开测试商店运行、记录路由冲突和缓存行为、成功传播一次变更，并阻止故意无效的草稿覆盖有效资源后，才能把该流程报告为已验证。其他人应当无需访问开发者电脑即可复现结果。
先做字段映射，再生成 Markdown
不要直接序列化整个 WooCommerce 商品对象。商品名、描述、属性、分类和 Variation 标识可来自 WooCommerce；Guidance、Limitations、Compatibility 和 Source 往往需要编辑字段。每条映射要说明适用于 ProductGroup 还是具体 Variant；缺少商家 SKU 时，不能暗中用数据库 ID、GTIN 或 slug 代替。
生成器只输出待审核候选稿。后台备注必须清除，实时价格、库存、优惠券、运费、支付和订单必须排除，Source 要解析到公开自定义域名。插件可注册 WordPress rewrite 或 REST route 提供 /sku.md，但最终以公开响应为准。
验证路由、缓存和文档图
在干净安装中测试固定链接、缓存插件、多语言插件、安全中间件和普通主题。保存状态、重定向、最终 URL、Content-Type、缓存策略、正文哈希和生成版本，再验证 Catalog 与所有商品文档。浏览器能打开并不够，因为它可能渲染了自动消费者应拒绝的 HTML 回退页。
生成和批准必须分开：商品变化产生 diff，编辑审核后原子发布，上一版本可回滚。只改库存不应重写稳定知识，材质、兼容性或限制变化才触发更新。WooCommerce 支持结论需要公开测试店、复现步骤、路由与校验证据、更新和回滚演示。
失败时继续提供最后一份完整版本
生成可能因无效商品、Source 不可访问或插件钩子异常而中断。新目录应先写入暂存位置，完整验证文档图后再一次切换；失败时继续提供上一批准版本并显示管理诊断。不能让新 Catalog 指向旧商品文档，也不能把半成品以成功状态公开。切换后同步清缓存，再从公开域名请求并核对哈希。
插件 MVP 应包含生成、编辑 diff、逐条来源、校验、原子发布、回滚和公开验证命令，并具备审批权限与后台转义。验收店应覆盖简单商品、Variations、缺少可选标识符、故意冲突和无效来源，明确哪些阻止、警告或允许发布。
发布后如何验证与回滚
上线后应从公网重新请求 /sku.md，检查状态码、MIME 类型、重定向链和最终字节，并保存验证时间与插件版本。更新商品数据时先生成候选文件、完成审核，再以原子方式替换公开版本；如果路由或内容校验失败，应恢复上一份已验证文件。这样可以避免用户在更新过程中读到半份文档，也让故障能够按版本定位。