第 3 章｜技术选型的保质期：从十年，缩到四年-平芜编程栈

上一章我们磨了一把刀：本质 vs 偶然。这一章把它落到一个最关键、也最容易踩坑的动作上——技术选型。因为绝大多数"给自己加偶然复杂度"的决定，都是在这里做出来的。
而这一章要先打破一个几乎所有团队都曾信过的幻觉：你以为你在选一个"能用十年"的框架。可框架本身的寿命，早就撑不到十年了。

一、先看一个真实的"保质期"数据：它在肉眼可见地变短

过去，一个技术栈"吃十年"是常态：企业级系统的生命周期动辄十年、十五年，选型时"能不能长期稳定"是第一优先级 [ref:10]。

但现在，情况反过来了。模型的迭代周期从"百天级"压缩到"周级"，技术红利期以肉眼可见的速度缩短[ref:1,5]；连"技能"本身都有了保质期——大约 24 个月就一轮迭代，旧架构写法、旧平台操作会随社区转移而迅速贬值[ref:2]。

翻译成一句刺耳的话：

你按"用十年"的标准选的技术栈，它的"技术生命"可能只有四年。

这不是危言耸听，是行业结构性变化：技术更替的节奏，已经快过企业系统的寿命。当你用一个"三年后可能就没人维护"的框架，去搭一个"本来想用十年"的系统时，这中间的六年，就是你要独自还的债。

二、那个真实案例：为"至少用十年"而选的微服务全家桶，四年就过时

我见过（也听过太多次）这类项目：

项目立项时，架构师说"这套微服务全家桶，至少能用十年"。于是上了注册中心、配置中心、网关、服务网格、链路追踪、消息队列……一整套。三年后，那批组件里有几个已经停止维护、有几个版本断代、有几个社区已经迁移到新方案。四年后，团队面临一个残忍的选择：要么"跟在旧栈上继续还债"，要么"大规模重构"。

这不是个例，而是有清晰的行业证据：

Uber 的支付体验平台，公开放弃了微服务，转向"合理规模服务"[ref:20]——大厂都在往回走，说明这套"全家桶"不是越用越香，是越用越重；
社区里有一个词，叫“千刀万剐的微服务”（Death by a Thousand Microservices）——它的核心观点恰恰是：“用无聊、过时的工具和技术写你的应用，没什么问题，你反而能构建出扎实可靠的东西；扩展性，等需要的时候再考虑”[ref:14]；
反过来，腾讯新闻推荐系统的重构是"300万行代码精简到30万，代码精简90%"[ref:19]——这说明什么？说明"堆出来的复杂度"，最终是要用"砍掉九成"来偿还的。

你仔细看这几条的共同指向：“选得越重、越流行、越’先进’，后期的债越贵。”你用"最流行"赌"最长期"，赌的是一个"框架不会老"的假设——而这个假设，已经被现实反复证伪。

三、为什么"框架会老，问题不会"？（这一章的理论核心）

因为它俩不是同一种东西：

框架 / 技术栈	你的业务问题
本质	偶然复杂度（实现手段）	本质复杂度（问题固有）
寿命	会老、会淘汰、会断代	不会老
变化	三年一轮、五年换代	十年可能就那么几条规则

看清这张表，你就懂了：你拿一个"三年就老"的框架，去承载一个"十年不变"的业务问题——你是在用"短命的东西"绑住"长寿的东西"。框架老了，业务还在，你就只能为了"迁就框架"而重构业务。这就是"系统短命"的真实机理。

所以第 2 章那句话，在这一章得到了最硬的印证：

别用"最流行"赌"最长期"——框架会老，问题不会。

四、那到底该怎么选？给你一个"选型前三问"

我不是要你"不用框架"，那是矫枉过正。我要你"别为流行和高级感选框架"，要为"问题"选框架。下次选型会上，拿这三个问题过一遍：

① 这个框架，是为我那两三处"本质复杂度"服务的吗？
如果它解决的，只是"看起来专业"，那它就是在给你加偶然复杂度。打样单逾期难在"判原因"，你上不上服务网格，跟这个难点无关——无关的，就别上。

② 如果这个框架三年后停止维护，我会不会"不得不重构"？
这是选型时最该问、却最少人问的一句。如果答案是"会"，那你就得在选型时就把"退出成本"算进去——要么选更稳更无聊的，要么把它藏在可替换的边界后面。“无聊的工具写扎实的系统"之所以成立，就是因为"无聊"意味着"活得更久”[ref:14]。

③ 删掉它，业务会不会受损？
删了不心疼的，都是偶然的；删了就塌的，才是本质的。这一问，能把一整张"看起来很必要"的技术清单，筛掉一大半。

外加一条铁律：扩展性、微服务化，等"真需要的时候再上"，别预先赌。[ref:14]

五、一个更本质的结论：你选的不该是"框架"，而是"边界"

既然框架一定会老，那专业团队的做法不是"赌对那个不老的框架"，而是：

把"一定会老的东西"（框架、中间件、技术栈），关在"可替换的边界"后面。

换句话说：你不该让业务逻辑"长在框架里"，而应该让业务逻辑"独立于框架存在"——框架只做它该做的脏活，且随时能换。这样框架老了你换框架，业务不用动；而不是框架老了，整个系统跟着重构。

这也正是"逼近问题"和"绕开问题"那把尺子的终极应用："选一个能陪我十年"是幻想；"让我的业务扛得住框架的十年三换"才是设计。

六、本章小结

技术选型的"保质期"，从十年缩到了四年——模型迭代从百天到周级，技能约 24 个月一轮贬值 [ref:1,2,5]。
真实案例：为"至少用十年"选的微服务全家桶，四年就过时——大厂都在往回走（Uber 放弃微服务 [ref:20]），“千刀万剐的微服务"提醒用无聊工具写扎实系统 [ref:14]，巨型重构往往是"300万行砍到30万” [ref:19]。
结论：别用"最流行"赌"最长期"——框架会老，问题不会。
选型前三问：为本质复杂度服务吗？三年后停维护会否被迫重构？删掉会塌吗？扩展性，等需要时再上。[ref:14]
你选的不该是"框架"，而是"边界"——让业务独立于框架，框架老了能换，业务不用动。