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、多一組服務器、多一個故障點?！?/p>

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

真正拍板的關鍵因素是金融場景的安全紅線。微服務返回的訪問令牌（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的企業版，但遷移過程中踩過冷啟動延遲的坑。

團隊技能樹要重修。前端工程師突然要處理服務端邏輯：數據庫連接池、下游服務超時熔斷、內存泄漏排查?！赣腥吮г梗艺械氖荝eact開發，不是Node運維，」技術負責人回憶。

故障排查變繞。一次支付失敗，日志要跨三層：瀏覽器控制臺→Next.js服務端日志→微服務日志。他們后來統一了Trace ID，但初期定位問題的時間確實變長了。

一個意外的場景

架構跑通后，團隊發現Next.js還解決了一個計劃外的問題。他們的產品要在第三方網站嵌入動態廣告，這些廣告需要實時拉取用戶偏好數據做個性化展示。

如果讓瀏覽器直接請求微服務，跨域配置和令牌傳遞都是麻煩。但走Next.js的API路由，同源策略天然成立，服務端還能做數據脫敏——比如把用戶ID哈希后再傳給廣告引擎。

「這個用法一開始沒在架構圖里，」技術負責人寫道，「但BFF層的位置太舒服了，順理成章就長出了新能力?！?/p>

目前這套架構已經支撐了8個月，峰值日活12萬，Next.js層平均響應時間控制在120ms以內。技術負責人的最后一條筆記是：「如果重新選，我會把API路由拆得更薄，只留安全和聚合邏輯，業務計算還是下沉到微服務?！?/p>

你的團隊在用Next.js做BFF嗎？是省事了，還是反而增加了心智負擔？