门禁与红线
四道门禁、十次破坏性演练、十一条红线。这一页不是讲义，是出事时要翻的那一页。
关键路径
14 个环节 · 4 道门禁从立项到维护，每一步都有产出物。门禁的标记不是装饰：它表示这一步卡住时，去改代码是无效动作。
四道门禁的归因
共同点：卡住时不是代码问题。把现象和真实原因对上，能省掉一整天的瞎试。
| 门禁 | 卡住的典型现象 | 真实原因 |
|---|---|---|
| ① ICP 备案 | 域名解析正常，但 80 / 443 完全没有响应 | 未备案，接入商在入口拦截 |
| ② 解析生效 | 本机能打开，别人打不开 | DNS 尚未传播 / 只改了本机 hosts |
| ③ 证书 | https 报证书错误或直接拒绝连接 | 域名未生效就申请，或自动续期已失败 |
| ④ 公安备案 | 站点正常，但收到整改通知 | 上线满 30 日仍未办理 |
十次破坏性演练
10 个阶段，各一次人真正学会是靠修，不是靠读。每一讲都有正常路径的练习，这里再补一层：故意搞坏，再修回来。 十条都是可逆的，且都写明了恢复路径 —— 在测试环境做，别拿生产练手。
拔掉网线，把你要用的工具从头点一遍，记下哪一步立刻卡住。目的是分清「本机能做的」和「必须有网才能做的」——后者才是你需要提前准备的通道。
新建一个临时仓库，提交一次后先 `git branch backup`，再 `git reset --hard HEAD~1`，然后从 backup 恢复。亲手验证「提交是可恢复的」，比背十遍命令有用。
把备案材料故意漏掉一页证件再提交，看驳回理由怎么写。在真项目上被卡一次要等好几天，在这里被卡只要几分钟。
把 nginx server 块里的 root 路径故意改错一位：`nginx -t` 照样通过，页面却 404。改回来。这一步是为了分清「配置语法对」和「路径对」是两件事。
把产物版本号改小再 push，看降级护栏是否把你拦下；改回来再推一次，确认恢复正常。没被拦过，就不知道护栏有没有接电。
建一张临时表写几行数据，做一次备份，然后删表，只从备份恢复。记下耗时和丢了哪几行——这就是你真实的数据底线。
从服务器日志抽 20 行原样存成 txt，再按脱敏规则处理一遍，逐行比对找出漏掉的字段。漏在哪，说明你的规则少了一条。
把测试机磁盘塞到 90%，看体检脚本退出码是否从「正常」跳到「告警」。跳了才算接通，没跳说明阈值写错了。
照交接文档发一次版，故意跳过其中一步，记录「漏了会怎样」。交接文档的价值，全在别人漏掉一步时还能不能被发现。
把邮件通知开关关掉（MAIL_ENABLED=false）重启服务，再提交一条留言：确认留言照常入库、只是不发信。这条演练是为了记住「通知失败 ≠ 数据丢失」——很多人一停邮件就以为表单坏了。
十一条通用红线
不分阶段，全程适用这些不是「最佳实践」，是底线。违反其中任何一条，出了问题都不该算意外。
- 改前先读，改后回读。不接受「应该改好了」。
- 一次只改一件事，一次只提交一件事。
- 密钥永不进仓库，永不出现在截图里。
- 生产目录只允许部署脚本写，人上服务器只读优先。
- 没演练过的备份，不算备份。
- 发布必须给「已上线 / 未上线」的结论，不拿绿勾当证据。
- 多站共存时，只动自己的 web 根目录。
- 权限最小化：能只读就别给写。
- 不确定就停下问，不猜、不编、不用「通常」糊过去。
- 任何「顺手优化」都要先回答：不改会怎样。
- 自造的词必须在使用处给定义，否则就是给别人留债。