做Node.js后端的朋友遲早要跟koa打交道。如果你一直用Express寫接口大概能理解那種感覺回調(diào)地獄雖然被Promise緩解了但中間件體系還是不夠順手每個業(yè)務(wù)里都夾著一堆模板代碼。koa從2015年前后進入大家視野喊出的口號是“小而美”——它不像Express那樣把路由、模板引擎、靜態(tài)服務(wù)都內(nèi)置進去而是只提供一個極簡的HTTP服務(wù)內(nèi)核剩下的路由、參數(shù)解析、跨域、日志全部交給社區(qū)中間件自由組合。這篇文章不是官方文檔的復(fù)讀我按自己從零上手到上線維護的真實路徑把安裝節(jié)點、中間件洋蔥模型、路由與參數(shù)、統(tǒng)一錯誤處理、PM2部署這些環(huán)節(jié)串一遍順便把我在實際開發(fā)里踩過的坑和排查思路寫出來。讀完你不僅能跑起一個koa項目還能知道每行代碼為什么這么寫。1. koa到底解決了什么問題Express太啰嗦異步太難受1.1 回調(diào)地獄與“中間件流水線”的舊困擾Node.js剛火那幾年Express是絕對的主流一個接口常常長這樣app.get(/user/:id, function (req, res, next) { User.findById(req.params.id, function (err, user) { if (err) return next(err); res.json({ data: user }); }); });單看這一段還好但真實業(yè)務(wù)里往往要查數(shù)據(jù)庫、調(diào)遠程接口、寫緩存、記日志層層嵌套之后就變成了傳說中的“金字塔代碼”一屏都放不下改起來更是膽戰(zhàn)心驚。后來社區(qū)用Promise和async/await做了不少補救但Express的中間件模型還是callback那一套你在async函數(shù)里拋出的異常不一定能被框架捕獲往往要自己包一層try/catch。koa的核心思路就是把中間件函數(shù)全部統(tǒng)一成async函數(shù)形態(tài)讓異常能順著Promise鏈往上傳配合統(tǒng)一的error事件就能全局兜底。用koa寫同樣的查詢接口代碼大概長這樣router.get(/user/:id, async (ctx) { const user await User.findById(ctx.params.id); ctx.body { data: user }; });沒有next(err)傳參沒有res.json手動封裝await完了直接塞給ctx.body整個讀起來和同步代碼差不多這對長期維護來說帶來的體驗提升是肉眼可見的。1.2 koa的設(shè)計取舍小而精把選擇還給你koa的源碼壓縮后很小核心只干了三件事封裝req/res為統(tǒng)一的ctx對象、維護中間件數(shù)組、啟動HTTP服務(wù)。沒有路由沒有模板引擎沒有靜態(tài)文件處理。我第一次看到也愣了一下連路由都要自己裝會不會太簡陋恰恰是這個“簡陋”給了項目很強的自由度。Express把東西都內(nèi)置好了看似方便但上了復(fù)雜業(yè)務(wù)你會發(fā)現(xiàn)內(nèi)置的實現(xiàn)不一定符合口味想換一套卻要跟內(nèi)置模塊糾纏。koa反過來默認給一個空殼你按項目需要自己拼接口項目裝koa/router和koa-bodyparser帶頁面的裝koa-static和koa-views要鑒權(quán)裝koa-session或自己寫JWT中間件。項目大的時候依賴清單本身就是一張架構(gòu)圖。當(dāng)然koa也繼承了Node.js生態(tài)的“野性”——選型你得自己負責(zé)裝錯了中間件得自己排查。這也意味著如果你想長期靠Node.js吃飯搞懂每一層是怎么拼起來的反而比用全家桶框架學(xué)到的底層原理更多。1.3 koa與Express核心差異速覽對比維度Expresskoa內(nèi)核體積較大內(nèi)置路由/靜態(tài)/視圖等極小核心只有中間件機制中間件模型線性流水線next進入下一層洋蔥模型支持中間件“進入—返回”的雙階段處理異步風(fēng)格兼容callback、Promise、async原生async/await異常沿Promise鏈傳遞錯誤處理next(err)逐層傳遞容易漏app.on(error)全局兜底路由內(nèi)置需安裝koa/router適用場景傳統(tǒng)MVC、老項目、快速原型輕量API服務(wù)、中后臺、微服務(wù)中的單個服務(wù)我在實際項目里兩種框架都維護過體感最強烈的不在語法細節(jié)而在“想做一個全局處理時的手感”。比如統(tǒng)一接口響應(yīng)格式、統(tǒng)一記錄請求耗時koa的中間件因為洋蔥模型的存在能很容易地在請求進來時計時、等整條鏈跑完再寫日志而Express要做到類似效果得靠中間件排列順序加上res的finish事件去配合麻煩不少。2. 環(huán)境準(zhǔn)備Node.js版本怎么選安裝時我踩過的坑2.1 版本選擇LTS優(yōu)先別碰奇數(shù)字先說結(jié)論日常開發(fā)和部署選Node.js偶數(shù)版本里的LTS也就是長期支持版。寫這篇文章時主流生產(chǎn)版本是20.x和22.x如果你是新項目又沒有特殊依賴直接裝20或22都不會錯。這里有一個不少剛接觸Node.js的人會犯的迷糊官網(wǎng)上寫著Current的奇數(shù)字版本比如23.x、24.x看起來是最新的但它的定位是“當(dāng)前迭代版”每六個月就換一輪API還在變動第三方原生模塊的兼容性也可能跟不上拿來做生產(chǎn)環(huán)境是給自己找麻煩。我在把測試服務(wù)器升級到24.x的時候就遇到過某個舊版node-sass的原生模塊編譯失敗查了半天才發(fā)現(xiàn)是Node版本太新那個庫還沒跟上。后來我給自己定了個規(guī)矩開發(fā)機可以留一份最新的Current用來嘗鮮但項目里的package.json寫清engines字段指定只允許LTS版本運行避免同事機器上版本五花八門。2.2 Ubuntu、Windows、macOS三條安裝路徑的記錄不同平臺的安裝方式不一樣但核心建議只有一個用版本管理器不要直接去官網(wǎng)下載二進制包。官網(wǎng)下載解壓就能用的方式對一次性環(huán)境沒問題缺點是想切版本很痛苦只能手動改環(huán)境變量路徑。我用得最多的是nvmNode Version ManagerLinux和macOS裝好后兩條命令就能搞定curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install --ltsWindows上沒有原版nvm社區(qū)維護的nvm-windows同樣好用裝完后執(zhí)行nvm install 22再nvm use 22就切過去了。這里有個小細節(jié)安裝完nvm后如果執(zhí)行node -v找不到命令多半是終端沒有重新加載配置文件手動source ~/.bashrc或者干脆重開一個終端窗口就行。Ubuntu用戶經(jīng)常做的第一反應(yīng)是apt install nodejs我勸你多留個心眼。Ubuntu軟件源里的nodejs版本通常比較舊安裝后node -v打出來可能是個古早版本連async/await支持都有問題更別說跑koa。如果你不打算用nvm也可以從Node.js官網(wǎng)下載官方編譯好的LTS包解壓后把bin目錄加進PATH比如追加到/etc/profile.d下的腳本里。2.3 “版本號尚未發(fā)布”這類報錯的排查思路搜索熱詞里有一條報錯很典型error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。這個我之前也遇到過明明官網(wǎng)上有這個版本號nvm卻提示“尚未發(fā)布”或者“不可用”很多人第一反應(yīng)是網(wǎng)絡(luò)問題其實大概率是nvm的遠端版本列表緩存太舊本地還沒同步到最新發(fā)布信息。解決辦法也不復(fù)雜。如果版本確實已經(jīng)發(fā)布先刷新nvm的版本列表再安裝nvm ls-remote nvm install 24.21.0ls-remote會重新拉取官方版本索引拉不下來的時候再看是不是nvm本身版本太老建議先升級nvm本體。還有另一種情況是版本號本身寫錯比如把24.21.0打成了24.210這種復(fù)制粘貼時特別容易出核對官方版本列表就好。如果你只是為了跑koa完全沒必要追最新版本號穩(wěn)定的LTS版本遠比“數(shù)字最大”重要。提示在開發(fā)機上裝好node后順手執(zhí)行npm -v確認npm也正常。有些手動安裝方式會把npm漏掉導(dǎo)致后續(xù)裝包全都失敗。3. 核心概念拆解ctx、中間件與洋蔥模型3.1 ctx一次請求里的“百寶袋”koa里每個請求都會生成一個獨立的ctx對象你可以把它理解成快遞員手里的那臺掃描終端里面既有包裹信息也有簽收界面。ctx上常見的屬性包括屬性作用典型用法ctx.request封裝的請求對象比原生req更好用ctx.request.query、ctx.request.bodyctx.response封裝的響應(yīng)對象ctx.response.status、ctx.response.set()ctx.params路由路徑參數(shù)來自routerctx.params.idctx.query查詢字符串解析結(jié)果訪問 /a?x1 時得到 { x: 1 }ctx.request.body請求體內(nèi)容一般由bodyparser填充讀取JSON請求體ctx.body快捷設(shè)置響應(yīng)體賦對象會自動JSON序列化ctx.status快捷設(shè)置響應(yīng)狀態(tài)碼ctx.status 201ctx.state中間件之間傳遞數(shù)據(jù)的小倉庫用戶鑒權(quán)后存user信息剛開始用koa的人容易在ctx.request.body和ctx.body之間犯迷糊。前者是從客戶端“拿進來的”后者是要“送出去的”代表了兩個完全不同的方向。中間件鏈上往前傳遞數(shù)據(jù)則用ctx.state我在后面講鑒權(quán)時還會提到。3.2 用一段代碼看懂洋蔥模型koa的中間件機制網(wǎng)上叫“洋蔥模型”名字很形象。你往app.use里塞一堆async函數(shù)請求從最外層中間件進入一路await next()往里走直到最后一個中間件處理完成再一層層返回。來直接看代碼const Koa require(koa); const app new Koa(); app.use(async (ctx, next) { console.log(1-請求進入); await next(); console.log(1-請求返回); }); app.use(async (ctx, next) { console.log(2-請求進入); ctx.body Hello Koa; await next(); console.log(2-請求返回); }); app.use(async (ctx) { console.log(3-處理業(yè)務(wù)); }); app.listen(3000);跑起來請求一次控制臺輸出順序是這樣的1-請求進入 2-請求進入 3-處理業(yè)務(wù) 2-請求返回 1-請求返回可以看到中間件代碼在await next()前后的部分會執(zhí)行兩次像剝洋蔥一樣進去又出來。這個特性最實用的場景就是計時和統(tǒng)一的響應(yīng)封裝外層中間件在進入時記錄startTime在返回前計算總耗時或者統(tǒng)一給響應(yīng)包一層結(jié)構(gòu)。如果用Express那套線性流水線想做這種“進去又出來”的雙階段邏輯就得繞圈子。3.3 中間件設(shè)計的幾條實用原則第一個原則是中間件順序極度敏感。比如日志中間件必須排在路由之前否則路由已經(jīng)處理完響應(yīng)了日志根本來不及記錄。bodyparser也得在路由之前不然路由里讀不到ctx.request.body。第二個原則是“一個中間件只做一件事”。我見過有人把日志、鑒權(quán)、參數(shù)校驗、業(yè)務(wù)處理全塞進一個app.use里幾百行中間件看起來很“集中”實際上改一個功能容易碰壞另一個。把功能拆成一個一個幾十行的中間件調(diào)試時按順序注釋排查效率高很多。第三個原則是中間件內(nèi)的代碼盡量保持“同步感”。使用async函數(shù)后await之間的邏輯是順序的但如果你在中間件里又開setTimeout、又搞eventEmitter異常就很難被koa統(tǒng)一捕獲容易變成unhandledRejection。一句話把異步邊界收緊在await表達式范圍內(nèi)別讓邏輯跑到中間件調(diào)用棧外面去。4. 路由、參數(shù)與body解析從0寫一個真實接口4.1 路由選型與常見坑koa本身不帶路由目前最主流的選擇是koa/router它是koa-router的維護版功能上沒有本質(zhì)區(qū)別包名換了但API基本兼容。裝好之后先實例化再掛載到app上順序和中間件一樣敏感const Router require(koa/router); const router new Router({ prefix: /api }); router.get(/health, (ctx) { ctx.body { status: ok }; }); app.use(router.routes()); app.use(router.allowedMethods());allowedMethods()這一行很關(guān)鍵它會讓接口對不支持的方法自動返回405或響應(yīng)Allow頭部比如只定義了get的地址收到POST請求就會被正確處理而不是流落到404。沒寫這行也不影響跑但接口語義就不完整。另一個坑是路徑前綴重復(fù)。比如頁面路由和接口路由都想用/user注冊順序后又沒有統(tǒng)一規(guī)劃請求很可能被第一個匹配的路由吞掉。我給每個子路由實例化時都會顯式寫死prefix這樣一眼就能看出哪些路徑屬于哪個模塊。4.2 參數(shù)怎么拿params、query和body接口開發(fā)里最常見的三類參數(shù)分別是路徑參數(shù)、查詢參數(shù)和請求體。路徑參數(shù)靠路由規(guī)則里的冒號定義router.get(/user/:id, (ctx) { ctx.body { id: ctx.params.id }; });查詢參數(shù)直接掛在URL后面比如/user/list?page1size10用ctx.query拿它會自動解析成{ page: 1, size: 10 }。注意拿到的是字符串如果要做數(shù)值計算記得先用Number轉(zhuǎn)換或校驗工具處理一下。請求體要分情況看。純GET接口一般不需要body但POST/PUT/PATCH發(fā)來的JSON、表單數(shù)據(jù)必須先經(jīng)過koa-bodyparser的解析才能在路由里讀取。裝好后在路由之前全局注冊const bodyParser require(koa-bodyparser); app.use(bodyParser());之后路由里就能這樣用router.post(/user, (ctx) { const { name, email } ctx.request.body; ctx.body { received: { name, email } }; });4.3 完整示例一套內(nèi)存版用戶接口為了展示“路由參數(shù)body響應(yīng)”的全鏈路我寫一個不依賴數(shù)據(jù)庫的用戶接口數(shù)據(jù)存在內(nèi)存數(shù)組里重啟丟失但夠用來理解流程。完整代碼長這樣const Koa require(koa); const Router require(koa/router); const bodyParser require(koa-bodyparser); const app new Koa(); const router new Router({ prefix: /api/users }); const users []; let nextId 1; app.use(bodyParser()); router.get(/, (ctx) { ctx.body { list: users }; }); router.get(/:id, (ctx) { const id Number(ctx.params.id); const user users.find((u) u.id id); if (!user) ctx.throw(404, 用戶不存在); ctx.body { data: user }; }); router.post(/, (ctx) { const { name, email } ctx.request.body; if (!name || !email) ctx.throw(400, name和email不能為空); const user { id: nextId, name, email }; users.push(user); ctx.status 201; ctx.body { data: user }; }); router.put(/:id, (ctx) { const id Number(ctx.params.id); const user users.find((u) u.id id); if (!user) ctx.throw(404, 用戶不存在); const { name, email } ctx.request.body; if (name) user.name name; if (email) user.email email; ctx.body { data: user }; }); router.delete(/:id, (ctx) { const id Number(ctx.params.id); const index users.findIndex((u) u.id id); if (index -1) ctx.throw(404, 用戶不存在); users.splice(index, 1); ctx.status 204; }); app.use(router.routes()); app.use(router.allowedMethods()); app.listen(3000, () { console.log(server running at http://localhost:3000); });這套接口里用到了ctx.throw(400, xxx)這是koa內(nèi)置的快速拋錯方式錯誤會被后續(xù)的統(tǒng)一錯誤處理接住。如果是小項目這個demo已經(jīng)是一份能商用的骨架了。真實項目只需要把內(nèi)存數(shù)組換成數(shù)據(jù)庫模型邏輯幾乎不用動。5. 統(tǒng)一錯誤處理與工程化結(jié)構(gòu)5.1 全局錯誤處理中間件try/catch別散落一地新手寫koa最容易出現(xiàn)的一副畫面是每個接口里都包一層try/catch然后return一個錯誤響應(yīng)。代碼一多錯誤格式五花八門前端對接的時候想罵人。正確做法是統(tǒng)一在中間件頂層攔截異常。先在路由之前注冊一個錯誤處理中間件app.use(async (ctx, next) { try { await next(); } catch (err) { ctx.status err.status || 500; ctx.body { code: err.status || 500, message: err.message || 服務(wù)器內(nèi)部錯誤 }; ctx.app.emit(error, err, ctx); } });中間件里await next()之后的異常不管是從路由throw出來的還是數(shù)據(jù)庫查詢拋出的都會被這里攔住。有了這個兜底業(yè)務(wù)代碼里可以放心丟異常參數(shù)不對就ctx.throw(400, 參數(shù)錯誤)用戶找不到就ctx.throw(404, 資源不存在)除非有特殊的裁剪需求否則接口里基本不需要手寫try/catch。ctx.app.emit(error, err, ctx)這行用于把原始錯誤發(fā)到應(yīng)用層的error事件監(jiān)聽里。建議在入口處掛一個監(jiān)聽把error記錄到日志文件或日志平臺避免生產(chǎn)環(huán)境只看得到“500”卻沒有堆棧線索app.on(error, (err, ctx) { console.error(server error:, err); });5.2 404與業(yè)務(wù)錯誤碼的約定koa默認對沒匹配到路由的請求返回404響應(yīng)體是空的。對純接口項目我習(xí)慣在路由之后補一個兜底中間件讓連路由都沒匹配上的請求返回統(tǒng)一格式app.use((ctx) { ctx.status 404; ctx.body { code: 404, message: 接口不存在 }; });注意這段一定要放在router.routes()之后否則所有請求都會先被它攔截路由就失效了。另外業(yè)務(wù)上有時需要區(qū)分“HTTP狀態(tài)碼”和“業(yè)務(wù)錯誤碼”比如登錄過期可以返回200但code為401此時字段名和語義需要文檔約定清楚。我常用的約定是HTTP狀態(tài)碼表達傳輸層狀態(tài)body里的code表達業(yè)務(wù)結(jié)果前端先看code再做分支。5.3 值得參考的目錄結(jié)構(gòu)項目無論大小我都不建議把所有路由寫在一個入口文件里。一個可維護性還不錯的目錄結(jié)構(gòu)大概是這樣的src/ ├── app.js # koa實例、中間件裝配 ├── index.js # 入口啟動服務(wù) ├── config/ │ └── index.js # 端口、環(huán)境變量集中配置 ├── middleware/ │ ├── errorHandler.js # 統(tǒng)一錯誤處理 │ ├── responseTime.js # 響應(yīng)耗時統(tǒng)計 │ └── auth.js # 登錄鑒權(quán) ├── routers/ │ ├── user.js │ └── order.js ├── controllers/ # 業(yè)務(wù)控制器處理req/res語義 │ ├── userController.js │ └── orderController.js ├── services/ # 業(yè)務(wù)邏輯層操作數(shù)據(jù)庫、調(diào)用外部API │ ├── userService.js │ └── orderService.js └── utils/ └── response.js # 統(tǒng)一響應(yīng)包裝函數(shù)分層的主線是路由只負責(zé)路徑和參數(shù)的映射controller做參數(shù)校驗和響應(yīng)處理service做真正的業(yè)務(wù)邏輯middleware處理橫切關(guān)注點。小項目可以砍掉controller層但service和middleware的隔離建議保留后面加單元測試、加需求時能省很多事。6. 常見問題與排查技巧實錄6.1 “ctx.body沒生效”一類問題你在路由里明明寫了ctx.body { code: 0 }但用Postman一請求返回卻是404空響應(yīng)。遇到這種情況先檢查路由有沒有真的注冊到app上最常見的原因是app.use(router.routes())寫到了中間件列表的末端被某個前置的ctx.body xx搶先兜底了。再檢查路由的prefix和請求路徑是否拼錯比如prefix是/api/users請求打的是/api/user路徑匹配不上自然走進404。還有一個容易被忽略的點ctx.body賦值后如果又寫了ctx.status 204204按協(xié)議不允許響應(yīng)體瀏覽器會自動丟棄body內(nèi)容哪怕你代碼里賦值了也看不到數(shù)據(jù)。6.2 中間件順序引發(fā)的連鎖反應(yīng)bodyparser順序不對是高頻問題。bodyparser要放在路由中間件之前因為路由里要讀ctx.request.body。如果順序反了請求先被路由處理路由里拿到空body然后你把空數(shù)據(jù)存進了數(shù)據(jù)庫回頭排查半天才發(fā)現(xiàn)是解析器還沒掛上。日志中間件也是一樣放路由后面的話路由都返回了日志代碼根本不會執(zhí)行到。我排查中間件順序時常用一個小技巧在每個app.use函數(shù)的開頭加一行臨時console.log(middleware A in)然后請求一次接口看控制臺輸出的順序和預(yù)期一不一致。定位完再刪掉日志比對著代碼猜快得多。6.3 async異常不輸出日志的坑koa能捕獲的是中間件Promise鏈上的異常但如果在中間件里用了不帶await的異步操作比如app.use((ctx, next) { setTimeout(() { throw new Error(boom); }, 100); return next(); });setTimeout里拋出的錯誤koa根本接不住也不會出現(xiàn)在app.on(error)里最終變成unhandledRejection在有些Node版本下進程還會直接崩掉。排查這種問題的方法是在進程級別掛上兜底監(jiān)聽至少讓你知道發(fā)生了什么process.on(unhandledRejection, (err) { console.error(unhandledRejection:, err); });但根因還得靠代碼規(guī)范中間件里的異步操作一律用await或把回調(diào)Promise化絕不讓異常脫離中間件的調(diào)用鏈。6.4 其他高頻問題速查表現(xiàn)象最常見原因處理建議端口被占用啟動報EADDRINUSE上一個進程沒退出lsof -i:3000找到PID并kill或改用其他端口請求對象返回的是字符串而不是JSON手動設(shè)置了Content-Type或ctx.body直接賦字符串給ctx.body賦對象即可koa會自動設(shè)置application/jsonPOST請求讀取不到ctx.request.body沒掛koa-bodyparser或掛載順序在路由之后在路由之前app.use(bodyParser())接口突然404路由未注冊、路由前綴拼錯、兜底中間件放錯位置用中間件日志定位是否有進入router.routes()外部POST請求跨域被攔沒配置CORS中間件使用koa/cors并設(shè)置允許的來源日志時間比本地時間差8小時服務(wù)器默認UTC時區(qū)在日志配置中顯式指定時區(qū)或統(tǒng)一轉(zhuǎn)換7. 上線部署與性能優(yōu)化要點7.1 PM2守護進程別讓進程自己死掉koa應(yīng)用本質(zhì)上就是一個Node進程上線時如果直接node src/index.js掛著一旦進程崩潰服務(wù)就完全不可用了。我平時用的是PM2做進程守護簡單配置如下npm install -g pm2 pm2 start src/index.js --name my-koa-app pm2 save pm2 startuppm2 startup會生成一條開機自啟命令讓服務(wù)器重啟后進程自動拉起。PM2還自帶日志和監(jiān)控面板pm2 logs看實時輸出pm2 monit看CPU和內(nèi)存。多核機器上建議開cluster模式讓進程按CPU核心數(shù)復(fù)制起來充分利用多核性能pm2 start src/index.js -i max --name my-koa-app不過開了cluster模式后要注意session和內(nèi)存數(shù)據(jù)不再共享如果代碼里有內(nèi)存緩存或者WebSocket連接會繞出跨進程一致性的問題。所以我的建議是接口純無狀態(tài)才放心用cluster否則先單進程跑瓶頸到了再去加架構(gòu)上的復(fù)雜度。7.2 環(huán)境變量與運行模式端口號、數(shù)據(jù)庫連接串、密鑰這類配置不適合寫死在代碼里用環(huán)境變量讀取是最基本的工程習(xí)慣。代碼里這樣寫const port process.env.PORT || 3000; const env process.env.NODE_ENV || development;PM2啟動時通過env字段或命令行傳入環(huán)境變量開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境用不同的配置避免把本地配置帶到線上。還有個細節(jié)生產(chǎn)環(huán)境一定要設(shè)置NODE_ENVproduction很多庫的日志詳細度、內(nèi)存用量都依賴這個值koa本身雖然不直接看它但它會影響你調(diào)用的其他中間件的表現(xiàn)。7.3 Nginx反向代理下要注意的細節(jié)實際部署很少讓Node直接暴露80端口對外訪問一般前端是Nginx做反代把接口請求轉(zhuǎn)發(fā)給Node進程。配置大概長這樣server { listen 80; server_name example.com; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }這時候如果代碼里需要獲取用戶真實IP直接用ctx.request.ip會拿到Nginx的內(nèi)網(wǎng)地址需要在koa入口設(shè)置一句app.proxy true讓框架信任X-Forwarded-For頭再去讀ctx.request.ip才是真實用戶IP。出于安全考慮這一句只在確認只有Nginx能把請求打到應(yīng)用時才開否則客戶端偽造請求頭會導(dǎo)致IP記錄失真。8. 最后關(guān)于koa的一些真實體驗8.1 什么時候該用koa什么時候別用做過幾個項目的橫向?qū)Ρ群笪椰F(xiàn)在的選型標(biāo)準(zhǔn)比較固定面向接口開發(fā)、團隊熟悉異步編程、項目需要靈活定制中間件的koa是很好的選擇。如果你的項目本身是傳統(tǒng)的服務(wù)端渲染頁面要模板引擎、要靜態(tài)資源托管、要現(xiàn)成的MVC結(jié)構(gòu)Express能讓你更快落地。如果你要的是一個全家桶框架自帶ORM、鑒權(quán)、定時任務(wù)、微服務(wù)協(xié)同那要去看NestJS這類重框架koa這類輕量內(nèi)核需要你自行拼裝的部分會太多。koa還有一個隱藏優(yōu)勢是學(xué)習(xí)成本曲線。它核心概念就那么幾個源碼也短新手啃一遍中間件機制后對Node異步理解會加深不少這種底子對后面接觸NestJS、寫AWS Lambda函數(shù)等都是保值資產(chǎn)。8.2 我從實踐中總結(jié)的幾條經(jīng)驗第一中間件一定要保持“薄”。我在代碼審查時看到過長到幾百行的app.use函數(shù)里面塞了十幾件事這種代碼看起來也能跑但以后任何人都不敢動它。一個中間件只做一件事做完了就把控制權(quán)交給下一個這是koa最優(yōu)雅的用法。第二路由層級和模塊邊界要在項目最開始就定好。prefix一旦在多個模塊里用起來后續(xù)想改路徑是牽一發(fā)動全身的事。我吃過一次虧前后端聯(lián)調(diào)時發(fā)現(xiàn)前端所有接口都寫的是/api/v1/...而后端路由是/api/...最后只能加一層路徑重定向兜底雖然解決了問題但顯得很丑。第三遇到奇怪問題先懷疑順序再懷疑緩存。koa的中間件順序和bodyparser掛載順序是新手翻車的第一大來源什么奇奇怪怪的“數(shù)據(jù)讀不到”“日志不打印”十有八九是順序問題。排掉順序之后再考慮是不是舊進程沒殺掉、端口被老服務(wù)占著、npm緩存了舊包這幾種排查路徑基本能覆蓋日常開發(fā)里近八成的幺蛾子。