业务后端复杂时不宜让 Next.js 承担架构边界

是什么

作者复盘内部问卷系统的技术选型：没有采用 Next.js 全栈，而是选择 NestJS + TanStack。核心判断不是 Next.js 能力不足，而是问卷的版本、权限、发布、答卷与统计等复杂度主要属于业务后端。

关键内容

视频认为 Next.js 的 Route Handler、Server Actions 与 Server Components 能快速交付，但若团队缺少明确分层，业务规则可能散落在页面、Action、Handler 与组件之间。NestJS 被用于提供模块、服务、鉴权、输入输出与异常处理等更明确的后端组织；前端则通过 API 消费服务状态与交互状态。

可借鉴之处

选型应先定位复杂度：内容、SEO 与轻量 BFF 场景可发挥 Next.js 的渲染和部署优势；业务规则复杂、调用方可能扩展时，应先定义稳定 API 与业务服务层。

边界与风险

这是单个项目经验，不构成 Next.js 不适合全栈的普遍结论。若团队能严格建立领域服务、契约与测试边界，也可使用 Next.js；反之，拆分 NestJS 服务同样会增加部署、联调和类型同步成本。