上一章我们磨了一把刀本质 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]你选的不该是框架而是边界——让业务独立于框架框架老了能换业务不用动。第二部分 · 代价为了显得高级选型会付出什么预告到这里第一部分立论讲完了没有银弹 → 分两类复杂度 → 框架会老。接下来第二部分把这些代价一笔一笔算清——不讲道理讲账单。第 4 章重架构的三种隐性账单对应你笔记里的“设计债 → 测试债 → 维护债的复利”——告诉你为了显得高级多堆的每一层最后是怎么变成没人敢动、动一下就出事的维护地狱的。第 5 章重构不是升级大型系统重构的真实成本——用300万行砍到30万 [ref:19]、“46 个模块级别的重构 [ref:ref] 这些真实数字告诉你当年那个’十年框架’后来是怎么被还债的”。