Next.js把前端后端全包了，1个框架扛下2份活

去年有个数据：全球Node.js项目里，43%已经在用Next.js做全栈。这不是跟风，是微服务架构里藏着一个反直觉的选择——让前端框架同时当后端入口。

一位金融科技团队的技术负责人最近分享了他们的实践。团队后端拆成了支付、用户、认证三个独立微服务，前端选了Next.js。但部署后他们发现，这个框架干了两个人的活。

架构图：浏览器只认识Next.js

具体结构长这样。`/app`目录下是React页面，用户看到的仪表盘、个人中心都在这里。但同级还有个`/app/api`目录，里面藏着三条路由：认证、支付、仪表盘数据聚合。

浏览器加载页面时，完全感知不到后端微服务的存在。它只和Next.js说话，Next.js再转身去敲微服务的门。这种设计模式叫BFF（Backend for Frontend，服务于前端的后端），但通常BFF是独立部署的服务，这里直接和前端代码住在同一个项目里。

「我们算过账，」技术负责人写道，「单独维护一个BFF服务，意味着多一套CI/CD、多一组服务器、多一个故障点。」

安全决策：令牌根本不落地

真正拍板的关键因素是金融场景的安全红线。微服务返回的访问令牌（access token），常规做法是丢给浏览器存在localStorage里。但XSS攻击一旦得手，令牌直接泄露，攻击者就能冒充用户操作账户。

Next.js的API路由运行在服务器端，这给了他们一个解法：令牌转成HTTP-only cookie再发给浏览器。JavaScript完全读不到这个cookie，即使页面被注入恶意脚本，攻击者也只能干瞪眼。

代码逻辑很直接。登录接口收到微服务返回的令牌后，立即塞进cookie属性里：`httpOnly: true`、`sameSite: 'strict'`。浏览器收到的只有`{ success: true }`，真正的令牌它从未见过。

「这是整个决策里权重最高的一条，」技术负责人强调，「安全优先，其他都是后话。」

代价清单：不是免费午餐

但省掉一个独立BFF服务，不代表没有成本。技术负责人列了三条明账：

部署复杂度上升。Next.js项目既要跑Node.js服务，又要做服务端渲染（SSR, Server-Side Rendering），内存和CPU占用比纯静态站点高出一截。团队最终选了Vercel的企业版，但迁移过程中踩过冷启动延迟的坑。

团队技能树要重修。前端工程师突然要处理服务端逻辑：数据库连接池、下游服务超时熔断、内存泄漏排查。「有人抱怨，我招的是React开发，不是Node运维，」技术负责人回忆。

故障排查变绕。一次支付失败，日志要跨三层：浏览器控制台→Next.js服务端日志→微服务日志。他们后来统一了Trace ID，但初期定位问题的时间确实变长了。

一个意外的场景

架构跑通后，团队发现Next.js还解决了一个计划外的问题。他们的产品要在第三方网站嵌入动态广告，这些广告需要实时拉取用户偏好数据做个性化展示。

如果让浏览器直接请求微服务，跨域配置和令牌传递都是麻烦。但走Next.js的API路由，同源策略天然成立，服务端还能做数据脱敏——比如把用户ID哈希后再传给广告引擎。

「这个用法一开始没在架构图里，」技术负责人写道，「但BFF层的位置太舒服了，顺理成章就长出了新能力。」

目前这套架构已经支撑了8个月，峰值日活12万，Next.js层平均响应时间控制在120ms以内。技术负责人的最后一条笔记是：「如果重新选，我会把API路由拆得更薄，只留安全和聚合逻辑，业务计算还是下沉到微服务。」

你的团队在用Next.js做BFF吗？是省事了，还是反而增加了心智负担？