有弱项有漏洞有欠缺有疏漏有不足有差距

去年冬天，有弱有欠我在一个技术评审会上看到一份架构方案。漏洞主讲人花了二十分钟讲系统优势，疏漏PPT翻到最后一页，差距有人问了一句：“如果缓存雪崩了怎么办？有弱有欠”他愣了两秒，说“这个我们后面会补”。漏洞那两秒的疏漏停顿，比整份方案都诚实。差距

任何系统都有弱项。有弱有欠问题不在于有没有，漏洞在于你知不知道它藏在哪儿。疏漏我见过一个跑了三年的差距推荐服务，QPS一直很稳，有弱有欠团队从没动过它。漏洞后来换了台机器重新部署，疏漏性能直接掉了四成。查了两天才发现，旧机器上有个被遗忘的ulimit配置，新机器没同步。这个弱项存在了三年，只是恰好没被触发。

漏洞和弱项不一样。弱项是能力边界，漏洞是边界上的裂缝。去年有个开源组件爆了反序列化漏洞，我们排查了一圈，发现内部有个服务确实用了，但版本锁死了，没受影响。松了口气。结果安全团队的人过来说，你们那个服务虽然没这个漏洞，但它用的另一个库，两年前就停止维护了。停止维护本身不是漏洞，但它意味着以后所有新漏洞都不会被修复。这比一个已知漏洞更麻烦。

欠缺往往是主动选择的结果。做技术方案时，不可能什么都覆盖。选A方案，就欠缺了B方案的扩展性；选快速上线，就欠缺了长期的代码整洁度。我参与过一个支付对账系统的重构，当时为了赶双十一，把对账频率从实时降到了每小时一次。业务方同意了，因为实时对账的成本是每小时对账的七倍。这个欠缺是明明白白写在文档里的，大家都知道，也都接受了。怕的是那种没人提、没人记、悄悄存在的欠缺。

疏漏是另一回事。疏漏不是决策导致的，是执行过程中漏掉的。上个月帮朋友看一个线上问题，日志里报空指针，查到最后发现是一个if判断漏了null检查。写代码的人说，他当时觉得上游一定会传值过来。这种“觉得”就是疏漏的温床。代码评审的时候，大家盯着业务逻辑看，没人去追问那个“觉得”到底靠不靠谱。

不足和差距，听起来像同义词，其实有区别。不足是你知道自己缺什么，差距是你以为自己有、但实际没有。有个团队一直觉得自己监控做得不错，直到有一次数据库连接池被打满，他们才发现监控只覆盖了应用层，数据库层的指标根本没采集。他们不是监控不足，是和“完善的监控体系”之间有差距——这个差距他们之前没意识到。

说这些不是要否定什么。一个系统能跑起来、能支撑业务，说明它的大部分设计是对的。但那些弱项、漏洞、欠缺、疏漏、不足、差距，不会因为你不看它就消失。它们只是安静地待在那里，等一个合适的时机跳出来。

我后来养成了一个习惯：每做完一个方案，专门花半小时想“这个方案哪里会出问题”。不是走形式，是真的去想。想出来的东西不一定都能解决，但至少下次有人问“缓存雪崩了怎么办”的时候，我不会愣那两秒。