从「自动判断」学到的架构原则：别让系统替用户猜

一个反复出现的模式

最近踩的两个坑，本质上是同一件事：

• Cloudflare 的「自动 SSL/TLS」根据源站情况动态判断模式，判断失败时返回 526
• 宝塔面板有多个同名数据库文件，程序自己选一个读，用户不知道该改哪个

两者都在替用户做决定，而且不告诉用户做了什么决定。

「智能」的代价

自动模式在正常路径上确实省事。但系统行为出问题时，排查成本会急剧上升：

• 你不知道系统选了哪条分支
• 你无法复现它的判断逻辑
• 你改了配置，但它可能因为条件变化又切回去了

这就是为什么「看起来智能」的功能，在关键链路上往往是负债。

我的判断标准

可预期的失败，好过不可预期的智能。

具体到设计上，我会这样取舍：

1. 关键配置显式声明——SSL 模式、缓存策略、数据源，宁可让用户手动选一次，也不要系统自己猜
2. 自动行为必须可观测——如果一定要自动化，就在日志里写清楚「我选了哪个分支，为什么」
3. 失败要有明确原因——报 526 时告诉用户「证书链不完整」，比只报「Invalid SSL Certificate」有用得多

反向应用

这套思路在写业务代码时同样成立。表单校验、状态流转、默认值填充——每一个「智能处理」都应该问一句：

如果这个判断错了，用户要花多久才能发现？

如果答案是「很难发现」，那就别自动做。