掘金上有个帖子火过一阵。

一个架构师，花了两个月精心设计了Schema级多租户隔离方案。数据表里加租户字段、查询自动拼条件、Row Level Security配得漂漂亮亮。技术评审的时候全票通过，PPT做了40页，架构图画得跟地铁线路图似的。

然后上线三个月，他把这套方案全部推倒，换回了最”原始”的一库一租户方案。

团队开发速度翻了3倍。

评论区炸了。有人说他在开倒车，有人说他不够专业。但他自己说了一句话：”我不是在倒退，我是终于清醒了。”

这件事让我想了很久。后来我发现，大多数系统的复杂度根本不是来自业务需求，而是来自工程师脑子里那句”万一以后需要呢”。

“万一以后需要”——工程师最贵的四个字

你有没有在技术评审会上听过这种对话？

“这个用单库就行吧？”“万一以后有100个租户呢？”“那……上Schema隔离？”“万一以后还要跨租户查询呢？”“那还是搞个中间层吧。”

一个原本只需要三天搞定的事，经过五轮”万一以后”，变成了三个月的工程量。而且这三个月做出来的东西，之后每一天的维护成本都是原方案的十倍。

你不是在做架构设计，你是在为一个可能永远不会到来的未来预付账单。 区别在于——这笔账单永远不会被退款。

我见过太多这样的项目。一个日活200的内部系统，数据库用了分库分表；一个只有3个开发者的团队，服务拆成了12个微服务；一个MVP阶段的产品，消息队列、配置中心、服务网格一应俱全——唯独缺用户。

Martin Fowler在博客里反复强调过一个观察：他参与咨询的系统重构项目中，绝大多数最终的结论是”简化”而不是”增加功能”。这跟你想象的正好相反——工程师花3个月搭建的微服务架构，最终又花6个月合回单体。前后9个月，系统回到了原点。唯一的变化是：团队的头发回不来了，项目经理的血压降不下去了。

复杂度的真实成本不在搭建那一刻，而在之后每一天的维护里。 搭建时你热血沸腾，维护时你生无可恋。

盖房子的人不会犯这个错

我来打个比方。

你买了一套90平的房子，家里就你和对象两个人。你会因为”万一以后家里来10个客人过夜”就现在就建10间卧室吗？

不会。正常人的做法是：等真有这个需求了，把书房临时改一下，或者让客人住酒店。

但工程师天天在做这个事。因为”万一以后有100个租户”就现在就设计Schema级隔离。因为”万一以后要支持10万QPS”就现在就上分布式缓存。因为”万一以后要国际化”就现在就把所有字符串都扔进i18n配置文件。

为什么盖房子的人不会犯这个错，而写代码的人会？

因为盖房子的成本是可见的——多建一间卧室，你立刻能感知到多花了20万。但写代码的成本是隐形的——多加一层抽象，当时感觉也就多写了几个类。你意识不到这几个类在未来半年会变成一整团拧不开的意大利面条。

YAGNI（You Ain’t Gonna Need It）不是懒，是对时间的尊重。 你今天写的每一行”以防万一”的代码，都是在向未来的自己收税。

为什么老手越来越爱”笨”方案

工作三年的工程师，给他一个问题，他会设计一个优雅的解决方案——抽象层、适配器、策略模式，恨不得把《设计模式》24章全用上。工作十年的工程师，给他同样的问题，他会问：”最蠢的方案能不能用？”

这不是退化，这是进化。也可以说是被现实毒打后的觉悟。

因为老手被坑过。他亲手写过那种”优雅的方案”，也亲手维护过。他知道上线之后会怎样——每次改需求都要改五个文件，每次排查bug都要跨三个服务追链路，每次上新人都要花两周讲架构，讲完新人脸上那个表情，就像你给一个刚学会骑自行车的人解释变速箱原理。而那个”笨方案”呢？改需求改一个文件，排bug看一个日志，新人来了看一眼就懂。

代码的优雅不是给同事看的，是给三个月后的自己看的。 如果三个月后的你看着这段代码想骂人，那它就不够简单。

有一种常见的辩护：”但简单方案不能scale啊！”

我的回答是：你确定你需要scale吗？

绝大多数创业公司在倒闭之前都没有遇到过scale的问题。他们遇到的问题是：过度设计的架构让团队跑得太慢，产品迭代追不上市场变化，然后死了。不是死于用户太多，是死于没有用户。你精心设计的分布式系统承受住了0个用户的并发访问，恭喜你，确实没崩。

既然老手们都学会了选简单方案，那问题来了——怎么判断什么时候该简单、什么时候真得上复杂方案？我总结了一棵决策树。

一棵决策树，三个问题

下次技术选型的时候，问自己三个问题：

第一问：当前用户量是否已经触达简单方案的瓶颈？

注意措辞——”已经触达”，不是”可能触达”，不是”万一触达”。如果答案是”还没有”，那就别换。先用简单方案把业务跑起来，等真到了瓶颈再说。

第二问：切换到复杂方案的迁移成本是否可控？

如果从单库迁到分库的成本是可控的（比如两周能搞定），那你就更有理由先用简单方案——因为你随时能切换，不存在”现在不做以后就来不及”的问题。反过来，如果迁移成本极高（比如要停服三天），那才值得提前规划。

第三问：复杂方案是否有团队里至少2个人能维护？

这是最容易被忽视的一点。一个只有架构师自己懂的方案，一旦架构师请假、离职、或者只是去上了个厕所回来忘了当时的设计思路，这个方案就变成了一颗定时炸弹。

如果三个问题的答案分别是”没有”“可控”“没有”，那就用简单方案。 别犹豫。

简单方案决策树

简单不是无能，是克制

回到开头那个架构师。

他把Schema隔离换回一库一租户之后，团队少了30%的联调时间，少了50%的数据bug，新人上手从两周缩短到两天。这些数字不是来自PPT，是来自三个月的实际运行数据。

有人问他：”你不怕以后租户多了扛不住吗？”

他说：”等那一天真来了，我再花两周迁移。比我现在每天多花两小时维护这坨东西划算多了。”

高级不是把简单的事做复杂，而是有勇气在所有人都选复杂的时候选简单。 这可能是工程师最难学会的一课。

KISS原则说的不是Keep It Simple Stupid——而是Keep It Simple So (future you won’t be) Stupid。

工程决策的反直觉

下次有人质疑你的方案”太简单了”，你可以理直气壮地回一句：

“简单不是我的能力上限，是我的选择。”