Next.js 13 Route Handler 和 BFF 的配合

Next.js 13 的 Route Handler 出来之后，很多人会自然地想到一个方向：既然前端项目里也能写接口，是不是可以把 BFF 这一层直接揉进去？我觉得答案不是简单的“可以”或“不可以”，关键还是边界。

对一些贴近页面的数据聚合、鉴权透传和轻量转换来说，Route Handler 确实很顺手。它能让前端页面和服务端逻辑靠得更近，减少单独维护一个小型 BFF 的摩擦。但只要开始涉及复杂业务编排、重状态流程或者跨系统集成，我还是更倾向把 BFF 保持成独立服务。

原因很现实：前端项目的迭代节奏、部署方式和后端服务并不完全一样。如果把过重的服务逻辑塞进 Next.js 项目里，后面维护责任会逐渐变模糊，团队也更难判断什么属于页面层，什么属于业务接口层。

我会把 Route Handler 看成一个很适合做“页面近端接口”的工具，而不是 BFF 的全面替代品。轻逻辑、轻聚合适合放进去，重业务、重编排还是应该留在更明确的服务边界里。

这样分工，Next.js 13 的一体化能力才会成为效率增益，而不是新的耦合入口。

前端里的很多“体验问题”本质上都是边界问题

围绕「Next.js 13 Route Handler 和 BFF 的配合」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。