实际使用与边界
适用场景：发布检查应针对公开域名：检查全新页面、文章、语言版本、sitemap、robots 和真实图片资源。把提交号和部署 URL 记入发布记录。
边界：构建成功不能证明域名路由、浏览器渲染、分析脚本或搜索收录正常。还应进行浏览器检查和 URL 检查。
从访客路径开始
打开首页、文章归档、单篇文章、隐私页、sitemap 和 robots 文件，确认全新加载时导航正常、文章页标题会变化。这些简单检查覆盖了访客、审核者和爬虫最可能走的路径。
用公开 URL 检查元数据
规范 URL、Open Graph URL、sitemap 和 robots 中的主域名必须一致。预览 URL 不应意外成为规范地址，文章标题和摘要应描述实际页面，而不是重复站点口号。
不依赖 JavaScript 技巧也要可读
服务端 HTML 应包含文章标题、摘要、标题层级和段落。链接要像链接，按钮要有清晰标签，颜色不能成为传达含义的唯一方式。页面快，但读者看不懂下一步，同样没有价值。
检查部署边界
不要把密钥放进 Git，使用示例环境变量文件，确保构建命令可重复。确认生产分支、域名别名和回滚路径。对小网站而言，知道如何回到上一个可用部署比复杂发布系统更有价值。
建立发布证据矩阵
用一张小表分别记录路由、元数据、可访问性、性能、表单、分析与抓取文件。每行写清具体检查、预期结果、证据和负责人。例如，规范网址检查应保存一个生产文章 URL 及其渲染 HTML 中的 canonical；死链检查应记录命令和失败数量。这样可以替代模糊的“看起来没问题”，并区分自动检查、人工抽样和明确延期的项目。
测试一次失败和回滚
发布计划至少要为一种重要失败准备响应。在预览环境中测试缺失环境变量或 API 不可用，确认页面会安全失败，再验证无需重新构建即可恢复到上一生产部署。上线后，从全新会话访问公开主域名，检查一个移动端页面，并确认 sitemap 与 robots 仍使用同一域名。这些检查覆盖了本地成功最容易在生产环境出意外的边界。
记录测试过什么
发布后记录提交、构建结果、公开 URL 和已知限制，让下一次维护更快，也让其他人可以复现检查。文档是生产产物的一部分，不是事后补充的手续。
常见问题
构建成功就足够发布吗？
不够。构建只能证明代码可以编译和生成路由，不能证明公开域名、重定向、元数据、链接和内容都正确。
部署后应该先检查什么？
先在全新会话打开规范的公开 URL，并走完主要访客路径。这能快速暴露本地构建无法证明的域名、重定向、资源、导航和环境差异。