上线前总清单与发布日 Runbook：把发布变成可重复的标准动作
发布事故大多源于「漏了一步」而不是技术不行。这一课给出功能/性能/兼容/安全/合规/数据/回滚七维上线清单、发布冻结与验收、发布日操作手册 Runbook 的写法，以及灰度放量、特性开关与金丝雀的具体策略
- 用七个维度的上线前清单系统性排查，不再靠记忆发布
- 理解发布冻结、验收标准与发布日 Runbook 的构成
- 掌握灰度放量、特性开关、金丝雀发布的策略与选择
- 能为自己的产品写一份可执行的发布操作手册
成熟的发布是「无聊」的：因为每一步都提前写好了
新手发布像走钢丝：深夜手动敲命令、边做边想、出问题临时搜。成熟团队的发布很「无聊」：有检查清单保证不遗漏、有操作手册保证动作一致、有灰度保证坏版本只影响少数人、有回滚预案保证随时能退。这一课把这套机制拆给你，独立开发者一个人也应该这样做。
上线前七维检查清单
① 功能：核心路径全部走通(注册/学习/AI/支付/进度同步)，无占位与死链
② 性能：首屏与关键接口响应达标、包体可接受、弱网可用、无内存泄漏
③ 兼容：主流机型/系统版本/屏幕尺寸、深浅色、横竖屏、WebView 版本
④ 安全：HTTPS、密钥在服务端、无调试接口、权限最小、输入校验与限流
⑤ 合规：隐私同意流程、数据映射一致、AI 标识、资质材料、隐私政策可访
⑥ 数据：备份已就绪、数据库变更可回滚、旧版本数据兼容(迁移脚本)
⑦ 回滚：上一版制品保留、回滚步骤明确且演练过、版本接口可控制强制更新
每项都要「可验证」，打勾要有证据(截图/命令输出/测试结果)，不能凭感觉新版改了数据库结构，老版本 App 或回滚后的旧后端会不会崩？这要求数据库变更向后兼容（先加字段、双写、再迁移，最后才删旧字段），而不是一步到位改表。回滚则要在发布前就确认：上一个可用版本的制品在哪、几条命令能退回、退回后数据怎么办。没演练过回滚的发布等于没有刹车。
发布冻结与验收标准
临近发布设代码冻结（Code Freeze）：冻结后只修阻断性 bug、不再加新功能，给测试留出稳定窗口。验收标准要提前定成可判断的条件，例如「P0/P1 缺陷清零、核心路径自动化全过、崩溃率低于阈值、灰度观察 N 小时无异常」，达标才允许全量，而不是「我觉得差不多了」。
发布日 Runbook：一份照着做的操作手册
Runbook 是把发布当天的操作写成顺序明确、任何人照做都不会错的文档：
发布 Runbook（每个产品维护一份）
1. 发布信息：版本号/versionCode、变更内容、影响范围、计划时间窗
2. 发布前确认：备份数据库、确认制品 MD5、确认监控与告警在线
3. 分步操作：每一步的具体命令、预期结果、实际结果记录栏
4. 灰度方案：先放多少(白名单/百分比)、观察多久、什么指标达标再加量
5. 验证：发布后立即执行的冒烟用例清单(含线上 URL/账号)
6. 回滚预案：触发条件、回滚命令、预计耗时、回滚后验证
7. 值守安排：谁盯监控、盯多久、异常联系谁
关键：先写好再发布，而不是边发边想；做完一步记录一步灰度、金丝雀与特性开关
特性开关是降低发布风险的利器：把「部署」和「对用户生效」解耦——代码可以先安全上线、功能默认关闭，确认稳定后远程打开；一旦新功能出问题，不用回滚发版、改个开关就秒级关闭。对独立开发者，一个简单的远程配置就能实现最基础的特性开关与紧急熔断。
灰度时到底盯哪些指标、盯多久（选学）
重点盯「对比类」和「红线类」指标：崩溃率、ANR/卡死率、关键接口错误率与延迟、核心漏斗转化（如注册→学习→完成）、支付成功率、新版与旧版/放量前后对比。红线一旦触及（崩溃率明显抬升、错误率超阈值、支付失败增多）立即暂停放量并评估回滚。观察时长要覆盖一个使用高峰周期（至少数小时到一天），因为很多问题只在特定时段、特定用户量下才暴露。
下列发布实践中，最能做到「新功能出问题时不用重新发版、秒级下线」的是？
本节小结
上线前七维清单：功能(核心路径无占位死链)、性能(响应/包体/弱网/泄漏)、兼容(机型系统尺寸深浅色WebView)、安全(HTTPS/密钥服务端/无调试/权限/限流)、合规(同意流程/数据映射/AI标识/资质)、数据(备份/变更可回滚/旧版兼容,先加字段双写迁移再删旧)、回滚(保留上版制品、步骤演练、版本接口可控强更)，每项可验证留证据。临近发布代码冻结只修阻断bug，验收标准量化(P0P1清零/崩溃率阈值/灰度观察时长)。Runbook含发布信息、发布前备份确认、分步命令与预期、灰度方案、发布后冒烟、回滚预案、值守安排，先写后发边做边记。发布策略：灰度分阶段、金丝雀小批对比、特性开关解耦部署与生效可秒级关、白名单内测；灰度盯崩溃/ANR/错误率延迟/核心漏斗/支付成功率并覆盖一个高峰周期，触红线即暂停。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
versionName 是给用户看的版本名，versionCode（构建号）只能单调递增、绝不回退，构建时间要和服务端升级清单一致。线上包、归档包、OTA 包必须用同一签名，并把文件大小和哈希（如 MD5/SHA）写进服务端元数据；客户端下载完成先校验哈希再安装，能从根上杜绝「下到一半的坏包被安装」。每次发版把这几项列成清单逐项核对。