13. 上线前先看最坏结果

约 30 分钟难度：进阶理解章

在本机上，工具只面对一种设备、一个网络、一个知道它脾气的操作者。公开访问之后，这三样都变了。这一章在上线之前，先把几类最坏结果逐条看一遍。

每一条检查都先摆一个可核验的后果，再给规则。后果只写和规则有关的事实，不渲染。

密钥不进代码，也不进 Git

后果：公开仓库里一旦提交过 API 密钥，会被自动扫描工具在很短时间内发现。这不是猜测，代码托管平台的密钥扫描和公开的泄露事件都能核验到这一点。

规则：密钥放进环境变量或专门的密钥管理，不写进代码，不提交进 Git。对静态网页还要多一句：前端代码对访问者完全可见，任何写进前端的密钥等于直接公开，没有「藏在代码里」这回事。

后果：第 11 章那位真实使用者，粘进了带表头的文本，工具把表头当成了一条报价。公开之后，会有各种预料之外的输入进来，空的、超长的、带奇怪字符的。

规则：解析任何外部输入之前，不假设它的格式。该跳过的跳过，该报错的给出看得懂的提示，不让一条坏输入把整个工具带崩。

后果：线上版本出错时，如果什么都没记录，事后只知道「有人说用不了」，不知道到底发生了什么，也就无从修起。

规则：留一条最小的出错记录和一个反馈入口。静态页至少要让使用者能把「点了什么、看到什么」反馈回来，不必一上来就上复杂的监控。

后果：一个权限过大的部署令牌一旦泄露，能被动用的范围远超过一个小项目本身。权限给得越宽，泄露时的波及面越大。

规则：部署用的账号和令牌，只给完成部署所必需的最小权限。这条原则有个名字，叫最小权限原则（least privilege）：每个部分只拿到完成自己任务刚好够用的权限，不多给。

后果：上线的新版本出问题，如果没有回退路径，就只能带着问题在线上现改，压力和出错概率都高。

规则：上线版本要能一键退回上一个已知可用的版本。这正是第 10 章练过的撤销一次提交，把它用到部署上。

后果：删除、覆盖、对外发送这类动作做完就收不回。交给自动流程无人看守时，一次误触就是不可逆的损失。

规则：不可逆操作不进自动流程，每一次都要人工确认。这条对后面接触资金、数据的项目尤其重要。

六类检查不该只停在抽象规则上，落到报价整理器这个具体项目，检查单大致是这样：

检查项	报价整理器现状	结论
密钥不进代码	静态页面本身不调用任何需要密钥的接口	不适用
外部输入不可信	第 11 章已补上表头跳过；货币符号、超长文本仍是第 3 章记录下的已知空白	部分通过，遗留项已记入待办
出错要留得下记录	目前没有任何出错记录，解析失败只在浏览器控制台报错，使用者看不到	未通过，部署前需补一个使用者能看到的提示
权限只给到刚好够用	部署令牌尚未申请，下一章按最小权限原则单独走一遍	待下一章确认
每一步都要能退回	项目全程在 Git 里，第 10 章已经练过撤销一次提交	通过
不可逆操作人工确认	报价整理器没有删除、支付、发送这类操作	不适用

这张表留下两条要带进下一章的遗留项：补一个使用者能看到的错误提示，以及申请一个权限刚好够用的部署令牌。检查单的价值不在于全部打勾，在于清楚记下哪几项现在还没做、要在哪一步补上。「未通过」和「不适用」都是诚实的答案，含糊过去才是问题。

这一章的产物是一份逐项有证据的上线检查单：每一条写清「最坏结果是什么、本项目具体怎么做、这一条算通过还是不适用」。逐项有证据，是为了让「可以上线」这个判断站得住。下一章拿着这份检查单，完成一次真正有人看守的部署。

这个操作可能不可逆。请列出它的失败方式、影响范围、回退条件，以及必须由我人工确认的步骤，先不要执行。