发布：更新：阅读：593
编辑提交一篇制造业文章，发布脚本返回成功，打开正式 URL 却仍看到旧标题；栏目页也可能暂时找不到这篇文章。遇到这种情况，只看后台记录或 HTTP 200 都无法判断发布是否完整。团队需要为每篇文章保留一条发布回执，用同一个文章 ID 对照数据库、公网页、栏目入口和 sitemap，哪一层不一致就停在哪一层处理。回执由实际执行验收的人填写，不能只复制发布脚本的成功输出。
写库前记录 run_id、article_id、原更新时间、filename、栏目 slug 和预期公开 URL。回执还要保存数据库与 sitemap 备份路径，以及本轮新增图片清单。这样遇到并发修改或缓存异常时，维护人员知道要比较哪条记录，也能确认回滚范围，不会按标题模糊查找后改到另一篇文章。
写入完成后，数据库层要核对目标 ID 的 title、description、content、subtitle 和 update_time。标题、description、filename 各自只能命中一条活动记录，subtitle 按站点规则保持为空；数据库还要返回 integrity_check=ok。文章使用扩展字段时，回执同时记录目标 ID 的扩展记录数量，防止主表已更新，附表仍引用旧值。
时间字段也要分开记录。datePublished 保留原发布日期，update_time 写入本次内容完成的真实时间，缓存清理时间只用于运维日志。sitemap 的 lastmod 应来自内容更新时间，不能把 sitemap 重建时间批量写给全部 URL。回执同时保存写入前后的最大文章 ID 和目标 update_time；其中一项在发布前发生变化，维护人员就重新读取目标记录，避免覆盖另一轮已经提交的内容。
正式 URL 应直接返回 200，不能经过临时跳转。维护人员随后核对 title、description、H1 和自引用 canonical，再比较正文可见字数、H2/H3 数量、图片与正文链接。Article 和 Breadcrumb 数据中的标题、发布日期、修改日期也要与页面一致。页面若仍出现旧标题或旧段落，应先判断缓存是否清理成功，再决定是否重新写库。
正文中的链接和图片逐个请求，记录最终状态与跳转位置。图片还要检查 alt、尺寸和主题；内链应指向标准伪静态地址。HTTP 200 只能证明服务器返回了页面，软 404、错误正文或指向其他页面的 canonical 仍属于发布失败。
栏目根页没有目标文章时，读取页面显示的分页链接，再沿真实页码查找目标 URL。PbootCMS 对不存在的页码也可能返回 200，盲目请求一串页码会形成错误验收记录。栏目较多时，可按内容 ID 核对相邻分页边界，确认文章没有重复出现或从排序边界漏掉。
sitemap 验收先解析 XML，检查 URL 集合没有重复，再确认目标 URL 恰好出现一次，lastmod 与本轮真实更新时间同日。URL 总数发生变化时，要比较写入前后的集合差异；数量稳定也不能代替目标项检查。新地址、canonical 和栏目 slug 的详细对照可参考sitemap 新 URL 验收方法。
回执完成后再标记本轮发布成功，内容包括各层结果、异常处理、备份路径、验收时间、责任人和复核结论。页面返回 200、进入 sitemap 或提交搜索平台，都不代表已经收录。搜索平台没有账号或 token 时，回执写“未配置、无法确认”，不把技术发布结果改写成收录结论。
