写代码一时爽，集成火葬场？

不知道你们有没有这种感觉——

信心满满选了技术栈：服务器框架用这个，ORM用那个，验证库又是另一个。文档看起来都很美，GitHub stars 加起来能绕地球一圈。

然后呢？

真正开始写功能的时候，验证库根本不认识 ORM 返回的数据结构。前端 SSR 跟服务器中间件打架。Session 处理逻辑在本地跑得好好的，一部署到边缘节点就各种报错。

每个工具单独拎出来都挺能打。一组合起来，就是一地鸡毛。

好端端的怎么变成这样了

JavaScript 圈一直有个执念：模块化、组合至上。这套思路从 UNIX 那边传过来的，确实挺好使。但问题是，Web 应用不是那种简单的一根筋数据处理流水线。

它是什么？

是各种隐性假设搅在一起的大杂烩：请求格式怎么定、验证边界在哪、认证流程怎么走、渲染上下文谁来管、部署目标是什么……全缠在一块儿。

2005 年 Django 出来的时候，它赌了一把：开发者愿意用一点灵活性换一套自洽的系统。框架内部的东西都是配套设计好的，你不用操心这个库和那个库能不能处得来。当然，真需要跳出去的时候也能跳，但正常情况下没那么多坑。

PHP 生态也懂这个理儿。Laravel、Symfony、Yii，给你的就是那种"一套系统"的感觉。你知道什么事是框架管的范围，什么事得自己出去折腾。边界清晰，不累心。

然后 JavaScript 把服务端也吃了，这套好东西基本就丢了。

Meta-Framework 的甜蜜陷阱

现代那些 meta-framework 其实让情况好了一些。Next.js、 Nuxt、SvelteKit，确实又给你整了一套统一的开发体验。

但它们怎么做到的？

答案是——收窄你的选择，而不是拓宽。

Next.js 是个好 React 栈，没毛病。但假如你突然看上 Solid 的性能，或者 Svelte 的简洁……抱歉，你换的不只是视图层。你得换整套 meta-framework，连带着路由规则、后端约定、开发习惯全部重来。你之前踩过的坑、填过的 bug，换个框架又得从头来一遍。

这就离谱了。

前端生态天天在创新，但你想换个思路？几乎等于重写一遍。React 开发者、Svelte 开发者，各自闷头解决同一套后端问题，代码长得差不多，本质上在重复劳动。

运行时这道坎

再说运行时碎片化。Node、Deno、Bun，都能跑服务端代码。但大多数框架实际上是跟某个运行时绑定的。

不是说"支持 Deno"就真支持了。很多时候它的意思就是"Deno 勉强能跑我们给 Node 写的代码"。这跟"针对 Deno 原生 API 和执行模型设计的框架"完全不是一回事。

这个差异比看起来重要多了。运行时选啥，直接影响性能表现、部署方式、安全模型。一旦选了个只在某运行时上才顺手的框架，以后想换跑道就麻烦了。

理想状态下什么样

Web 应用其实有天然的分层，各层之间本来不需要耦合。

• 前端负责浏览器 UI
• 后端处理请求、数据、业务逻辑
• 运行时是执行环境

这三件事完全应该独立演进才对。

想象一下：有些页面用 React，因为需要它的组件生态；另一些页面用 Svelte，因为性能更重要。Node 环境的路由先跑着，等哪天需要更快，直接把 TypeScript 那部分切到 Bun 上跑。全都在一个应用里，共享同一套后端模型、同样的验证逻辑、同样的 Session 处理。

这不是异想天开。这叫关注点分离，是软件工程的老道理了。

框架得管好自己的"接缝"

我不是要搞大一统、一个框架统治世界那套。

我想说的是：框架至少应该把自己内部的零件整明白、配合好。你当然可以跳出去用第三方方案——现实世界哪有框架能满足所有需求呢。但只要你在框架边界内用，它的各个部件应该配合得天衣无缝。

如果一个框架逼着你把路由、验证、数据读写、页面渲染当成四个独立问题，自己想办法粘合起来……

那它根本算不上框架，顶多是个半成品建议包。

真正好的框架是这样：业务逻辑归你管，其他破事儿归它管。让你省心省力，而不是让你天天当救火队员。

在 NameOcean，我们见过太多次了：技术栈越碎，部署复杂度越高，运维成本越离谱。

选一个尊重分层的框架——能让你换零件不用推倒重建——部署、扩容、维护都会轻松很多。

问题从来不是"要不要用框架"，而是"你的框架是真的在帮你，还是在给你添堵？"

下次起新项目之前，不妨想想：有没有一种工具，能把这些接缝问题都替你解决了？

想清楚再动手，不亏。