后端框架的终极困境：为什么我们不再需要“全家桶”
当我们谈论后端框架时，脑海中浮现的往往是Spring Boot、Django、Ruby on Rails这些庞然大物。它们承诺“开箱即用”，提供从ORM、鉴权到消息队列的全套解决方案。但在二十年后的今天，我越来越确信这些“全家桶”框架已经成为现代软件系统复杂性的主要来源之一。不是因为它们做得不够好，恰恰是因为它们做得太多——多到模糊了业务与基础设施的边界，多到让团队在技术选型时首先考虑“框架怎么用”而不是“业务怎么建”。
框架的本质是一种“约束下的便利”——它用约定俗成的结构和默认行为换取开发效率。然而，这种交换在微服务和云原生时代变得极其可疑。当你的系统被拆分成几十个微服务，每个服务都需要独立的部署和扩展时，一个统一的全栈框架实际上在强制所有服务共享同一套技术栈、生命周期和依赖治理方式。这看似降低了运维成本，实则遏制了每个服务发挥其独特性能的机会。例如，一个高频计算的服务可能只需要轻量级HTTP框架，而一个事务密集型服务则需要强一致性的持久层支持。全家桶框架迫使你为所有服务支付相同的“入场费”。
更值得警惕的是，框架的“粘性”会逐渐侵蚀架构决策的自主性。当团队依赖Spring Data的Repository抽象时，他们不再思考数据访问模式是否适合当前场景；当Django的Admin后台成为默认配置时，团队很可能忽略了非CRUD业务逻辑的表达。框架的抽象层不是为了让你思考，而是为了让你不思考。于是，技术决策从“业务需求驱动”异化为“框架功能驱动”。我接触过大量系统，其核心业务逻辑被模型层、控制器层和服务层层层包裹，实际上却只是对数据库表的机械映射——这就是所谓的“框架式贫血模型”。这种反向适配带来的长期维护成本，往往在项目中期集中爆发。
因此，我提出一个反主流的观点：抛弃“框架先行”的思维，转向“能力切片”的轻量集成。具体来说，不要选择一个框架，而是选择一组可组合的库——用Express或Fastify处理HTTP，用Prisma或jOOQ处理持久化，用JWT或OAuth库处理认证，用Registry模式管理依赖注入。这些库各自解决一个具体问题，且没有强制你接受一套完整的应用结构。同时，采用“业务边界”作为模块划分的准则，让业务实体和领域服务成为系统的骨架，而框架代码仅仅是周边插座。这种做法的好处是多方面的：技术栈的每个部分都可以独立升级；技能不足时可以用更简单的替换项；更重要的是，代码的可读性和业务表达力显著增强。诚然，这会牺牲一些“初始化开发速度”，但在长期维护和演进中，它为你赢得了巨大的灵活性。
未来，后端框架的方向应当是“退化”为更底层的运行时协议（如WebAssembly）加一组可插拔的处理器。而不是继续向上层吞并更多功能。我预测，像Spring这种全能型框架会逐渐边缘化，取而代之的是类似“功能即组件”的范式——你只引入你真正需要的，而框架本身只是一个薄薄的引导层。这才是对技术和业务双重尊重的演进路径。不要让你的架构被框架绑架，而要成为框架的裁缝，依据业务裁剪出最合适的外衣。
