发布前清单

在向真实用户开放产品前的全面门禁检查 — 基础设施、内容、分析、支持和法律就绪。

为什么

发布前清单把混乱的、基于希望的发布变成确定性的、基于门禁的发布。你遗忘的每一项都会变成面向用户的故障：注册崩溃、未测试的支付、营销页 404、无人值守的支持收件箱。清单强制团队一次性验证基础设施、内容、分析、支持和法律五个维度的就绪，让发布日是执行而非发现。跳过此步的产品把可见 bug 发给首批用户，第一周在救火而非学习。签字确认的清单也是让干系人同意产品真正就绪（而非仅"代码完成"）的凭证。

何时使用

代码功能完成并合并到 main 之后、任何公开 URL 可访问之前。在目标发布日前 1-2 周运行清单，让失败项有时间修复。

如何做

1. 基础设施：验证生产构建干净部署、DNS 解析、SSL 证书有效、CDN 缓存已清、错误监控（Sentry）已接、可用性监控已开
2. 功能冒烟测试：用全新账号在生产环境端到端完成前 3 条用户旅程（注册、核心动作、支付如适用）
3. 内容：每个营销页有终稿文案、OG 图在 Facebook/Twitter/LinkedIn 卡片验证器中渲染、favicon 和 app icon 已部署
4. 分析：所有关键页触发页面浏览事件、转化漏斗已配置、测试访问后 5 分钟内仪表盘显示数据
5. 支持：help@ 收件箱有人值守、状态页上线、应用内帮助/反馈组件已接、FAQ 页回答前 10 个预期问题
6. 法律：隐私政策和服务条款已发布、需要时 cookie 横幅存在、GDPR/数据删除端点可用
7. 回滚计划：记录部署 SHA、回滚命令、可授权回滚的决策人
8. 签字：每个维度负责人将自己的项标绿；仅当所有项为绿时授权发布

示例

# 发布前清单 — ez4code v2.0
日期：2026-10-04  负责人：@launch-lead

## 基础设施
[x] 生产构建干净部署（wrangler pages deploy）
[x] DNS：ez4code.com 解析到 Cloudflare Pages
[x] SSL：ssllabs.com 评 A
[x] Sentry：staging 错误率 < 0.1%
[ ] 可用性监控：UptimeRobot 5 分钟 ping  <-- 失败

## 功能
[x] 注册 → 仪表盘 → 创建项目 → 部署
[x] 支付：Stripe checkout + webhook + 发票
[ ] 密码重置邮件 < 30 秒到达  <-- 慢

## 内容
[x] /launch、/growth、/maintenance 页面终稿
[x] OG 图：1200x630，验证器中渲染
## 分析
[x] GA4 page_view 在全部 47 页触发
[x] 转化漏斗：访问 → 注册 → 部署
## 支持
[x] [email protected] → Zendesk，4 小时 SLA
[x] status.ez4code.com 上线
## 法律
[x] /privacy 和 /terms 已发布
[x] Cookie 横幅：OneTrust
## 回滚
SHA：a1b2c3d  回滚：wrangler pages deploy --branch=prev
决策人：@cto

## 签字
基础设施：绿  功能：黄  内容：绿
分析：绿  支持：绿  法律：绿
=> 未就绪：2 个黄项必须在发布前转绿

常见问题

⚠把"代码完成"当"发布就绪"— 清单存在的意义正是两者不同；代码完成指功能可用，发布就绪指用户不会撞到明显故障。
⚠在 staging 而非生产跑清单 — staging 与生产发散（不同环境变量、不同数据、不同 CDN）；在真实部署目标上验证。
⚠无回滚计划因为"我们就往前修"— 当部署在第一小时弄坏 1000 个新用户的注册时，往前修太慢；你需要 30 秒回滚。
⚠靠问"做完了吗"而非验证来勾项 — 清单负责人必须点链接、跑命令、看数据；口头确认掩盖缺口。

最佳实践

✓把清单做成单一共享文档（Notion/Linear），每节一个负责人加截止日；"共享"指所有人实时看到黄/红项，而非等周会。
✓把能自动化的项（部署健康、SSL 到期、分析触发、可用性）全自动化进 CI 门禁；人只验证主观项（文案质量、FAQ 完整度）。
✓加一步"暗发布"：以 0% 灰度部署到生产 feature flag 后，对真实生产环境跑清单，再逐步放量 — 在任何用户看到前抓住生产独有问题。
✓清单随代码版本化进 git；它随产品演进，成为每次发布"就绪"含义的审计轨迹。