2026-10-16 · 上线实录 ④ / ④ · 方法论
「看起来成功了」
是最贵的假象
一天下来，我们至少五次收到「成功」的信号——认证成功、命令没报错、配置显示生效—— 而它们全都不是真的成功。
这一天的技术活其实都不难：发布静态站、改几条 DNS、配一个邮箱。真正花掉时间的是另一件事—— 分辨真假。下面这份对照表是当天最实用的产出，可以直接拿去用。
| 看起来成功了 | 真正的证据 |
|---|---|
| SSH 提示「认证成功」 | 用一把不该成功的密钥试一次 |
| 克隆命令跑完了 | 数据包真的从 0 字节长起来 |
| 发布脚本说「已上线」 | 线上页面与本地文件逐字一致 |
| 邮箱记录「添加成功」 | 向权威服务器查到 MX / SPF 真的在 |
| 收件人地址可用 | 同域下编一个不存在的地址，看它怎么回 |
| 后台显示一切正常 | 策略列表里没有一条「禁止三方客户端」 |
三条能直接用的办法
一、反证法。想知道一个「通过」是否可信，就拿一个注定失败的样本再试一次。 两把钥匙都能开门，那门就是假的；两个地址都回 250，那测试就是没意义的。
二、看结果，不看退出码。命令没报错只说明它跑完了，不说明它做对了。 判断发布是否成功，就去看线上那个文件到底变了没有。
三、让验证保留失败的可能。好的检查必须存在「失败」这个分支。 如果一段验证永远不会失败，那它不是验证，是自言自语。
顺手记下的一件事：密码怎么存
这一天的功课里还有个小实践：邮箱凭据不该以明文躺在文件里。现在它用系统自带的 DPAPI 加密存储——密文只在这台机器上解得开。文件被拷到别的电脑、同步进网盘、 或者哪天误提交进 git，都是一串没有意义的字符。
这也算同一条原则的应用：别让「东西放在那儿」等于「东西是安全的」。
最后
现在这套东西的状态是：站点一条命令发布、域名解析干净、邮箱能收能发。 今天最值钱的一课也留在这里——
「看起来成功了」是最贵的假象。要拆穿它，办法只有一个：找一个能区分真假的证据。