NestJS 是一個以 TypeScript 為基礎的 Node.js 伺服器端框架，2026 年 8 月 27 日推出第十二個主要版本。截至 2026 年 10 月 18 日，專案在 GitHub 累積 76,857 顆星標、8,589 次複製與 22,253 次提交，貢獻者規模約 786 人，採用 MIT 授權，核心套件 @nestjs/core 在 npm 的單月下載量約 6,648 萬次。第十二版的核心改動集中在三處：核心套件全面改以 ESM 形式發佈、驗證與設定改用標準 Schema 規格，以及透過 @nestjs/observe 提供與框架生命週期整合的原生可觀測性。
NestJS 12 是什麼？
NestJS 12 是這套 Node.js 框架於 2026 年 8 月推出的主要版本，核心套件全面改以 ESM 形式發佈，並引入標準 Schema 驗證與原生可觀測性 SDK。
專案由 Kamil Mysliwiec 於 2017 年 2 月建立，設計上大量借用 Angular 的分層與依賴注入概念，把控制器、服務與模組的組裝方式固定下來，底層預設使用 Express，亦可切換至 Fastify。專案過往的定位並非與 Express 這類極簡框架競爭，而是補上伺服器端應用最常見的架構缺口，讓測試、擴充與長期維護有清楚的分界。
第十二版延續同一條路線，但改動幅度覆蓋整個生態系統。官方發佈說明指出，現有 CommonJS 應用在多数情況下無需改寫即可升級，因為現代 Node.js 已支援 require(esm)；是否把自家程式碼遷移到 ESM 仍屬可選項。相對地，nest new 建立新專案時會詢問採用 CommonJS 或 ESM，兩種選項各有對應的測試與建置預設值。
NestJS 12 的 ESM 套件化帶來什麼改變？
所有 Nest 核心套件改以 ESM 形式發佈，新專案可選擇 CommonJS 或 ESM，並要求 Node.js 20.19 或 22.12 以上，21.x 不獲支援。
套件格式轉換是這一版最根本的變化。官方說明，require(esm) 機制讓既有 CommonJS 應用得以照常運作，但自行撰寫的啟動腳本、建置工具鏈與測試執行器若有 CommonJS 專屬假設，仍需要逐一檢視。專案亦明確列出執行環境門檻：升級指令會拒絕在舊版 Node.js 上執行，包含整個 21.x 系列。
這項改動的連帶效果出現在測試與打包層。新建立的專案在 ESM 模式下預設使用 Vitest，CommonJS 專案則沿用 Jest；打包器方面，Rspack 成為單一儲存庫的預設選項，原有的 webpack 相關旗標與設定欄位被標示為棄用，官方建議改用 --builder rspack。對已在維運中的大型專案而言，升級路徑因此同時涉及執行環境、測試與建置三層。
NestJS 12 如何統一驗證與序列化流程？
路由裝飾器新增 schema 選項，可搭配 Zod、Valibot 與 ArkType；序列化與設定模組改用同一規格，class-validator 流程維持不變。
驗證機制的調整以標準 Schema 規格為核心。@Body()、@Query()、@Param() 與 @RawBody() 這幾個裝飾器新增 schema 選項，開發者可把既有的 Zod 或 Valibot schema 直接掛上，再註冊 StandardSchemaValidationPipe 進行驗證。官方強調，裝飾器本身只負責附加中介資料，實際驗證仍由管道處理，因此行為邊界與過去一致。
序列化與設定模組同步跟進。StandardSchemaSerializerInterceptor 讓回應輸出的驗證與轉換沿用同一批 schema；@nestjs/config 的 validationSchema 不再限定 Joi，改為接受任何相容規格，既有 Joi 使用者需升級至第十八版以上，並把函式庫專屬設定移入 validationOptions.libraryOptions。以類別為基礎的 DTO 流程仍完整保留，官方表明沒有移除計畫。
@nestjs/observe 原生可觀測性解決了什麼問題？
該 SDK 直接接入框架自身的請求生命週期，而非在 HTTP 伺服器層修補，能自動涵蓋 HTTP、GraphQL、gRPC、佇列消費者與排程工作，無需另設收集器。
傳統 APM 代理的運作方式是在伺服器層攔截請求，因此追蹤結果往往只剩下一條 HTTP 路徑。新推出的 NestJS Observe 改以應用選項 instrument 接入框架內部的請求生命週期，回報內容以控制器、提供者、解析器與佇列消費者為單位，軌跡讀起來更接近呼叫關係圖。
涵蓋範圍包括 HTTP、GraphQL、gRPC 與微服務傳輸，以及佇列消費者與排程執行，開發者不需要手動建立追蹤區段，也不必自行架設收集器。官方提供的免費額度為每月三十萬筆事件，並附設無需註冊的線上示範看板。這項功能屬可選項目，nest new 與 nest upgrade 均可透過 --observe 旗標協助接線。
NestJS 12 的 CLI 與工具鏈有哪些更新？
CLI 全面重寫為 ESM，新增升級與雲端部署指令，Rspack 成為單一儲存庫預設打包器，oxlint 取代 ESLint，並支援 bun。
命令列工具在這一版被完整重構，原始碼遷移為 ESM，測試框架由 Jest 換成 Vitest，每個指令都補上端對端測試，指令類別改為接收具型別的內容物件。新增的 nest upgrade 指令可把第十一版專案升上第十二版，並自動套用遷移中屬於機械性的部分，包括設定檔中的 webpack 選項、GraphQL 的 playground 更名，以及多項相依套件版本調整；官方建議先以 --dry-run 檢視變更清單。
另一個新指令 nest deploy 負責把應用部署到官方雲端服務 Mau，首次使用時會自動安裝對應套件，並把參數原樣轉送。工具鏈的預設值同時出現數項更替：新專案改用 oxlint 取代 ESLint，bun 與 npm、yarn、pnpm 並列為支援的套件管理器，而 angular 範本指令已被移除。建置選項新增 --parallel 與 --emit-declarations，後者用於 SWC 編譯情境。
NestJS 12 有哪些破壞性變更需要注意？
生命週期鉤子改按元件階層呼叫，NATS 套件換為新模組，GraphQL 訂閱改用 graphql-ws，GraphiQL 取代 playground，日誌參數預設啟用。
影響範圍最廣的一項是生命週期鉤子的呼叫順序。官方說明，初始化、銷毀與測試期間的鉤子改為依元件階層層級觸發，涉及多個提供者或模組之間順序假設的專案需要重新檢視。訊息傳輸方面，舊有 nats 套件被 @nats-io/transport-node 取代，封包改以 JSON 字串序列化，自訂反序列化器會收到完整的 NATS 訊息物件。
GraphQL 使用者面臨兩項變動：subscriptions-transport-ws 支援被移除，必須改用 graphql-ws，由於兩者協定不相容，客戶端需要一併更新；預設的圖形化 IDE 由 playground 改為 GraphiQL，設定方式改為傳入選項物件。其餘項目包括自訂管道簽章因 ArgumentMetadata 改為泛型而需調整、ConsoleLogger 的結構化參數改為預設啟用，以及 webpack 命令列流程被標示棄用。官方指出，這些項目大多可由升級指令自動處理。
NestJS 12 的工程數據與維護規模如何？
專案累積 76,857 顆星標、8,589 次複製與 22,253 次提交，約 786 位貢獻者，已發佈 170 個版本，採用 MIT 授權，核心套件單月下載量約 6,648 萬次。
維護節奏在第十二版發佈後維持穩定。從 2026 年 9 月至今已推出九個版本，最新一版為 10 月 12 日的 v12.1.3，內容以 SSE 串流生命週期、請求範圍增強器與 Express 中介層邊界案例的修正為主。儲存庫的公開議題數量維持在三十三項，其中屬純議題者僅九項，其餘為合併請求，反映專案把問題分流至官方討論區與社群頻道的策略。
NestJS 12 與其他 Node.js 框架有何不同？
與 Express、Fastify 等極簡框架相比，NestJS 提供現成的應用架構與依賴注入；代價是學習曲線較陡，換來大型團隊較一致的分層與測試方式。
差異主要在問題設定的層次。Express 與 Fastify 解決的是路由與請求處理，應用結構交由開發者自行決定；NestJS 則把模組、提供者、控制器與依賴注入定義成框架的一等公民，並以裝飾器描述中介資料。這種取向適合人數較多、需要長時間維護的專案，但也意味新進成員要先理解框架的分層約定。
第十二版的多項改動都指向同一目標。原生可觀測性讓追蹤結果以框架概念呈現，標準 Schema 讓驗證與設定規格外部化，升級指令則把主要版本的遷移成本壓低。這些安排都降低了框架本身與應用程式碼的耦合程度，也讓 Upgrade 路徑不至於成為專案的長期負擔。
出處連結有哪些？
本文資訊整理自 NestJS 的 GitHub 儲存庫與官方發佈說明，包含第十二版遷移指南、可觀測性文件、CLI 重構說明，以及 README 所述的專案定位與贊助模式。
- GitHub 儲存庫：https://github.com/nestjs/nest
- 第十二版發佈說明：https://github.com/nestjs/nest/releases/tag/v12.0.0
- 遷移指南：https://docs.nestjs.com/migration-guide
- 可觀測性文件：https://docs.nestjs.com/observability/overview
- 官方網站與文件：https://docs.nestjs.com
總結：NestJS 12 適合什麼團隊？
適合已採用 NestJS 且需要統一驗證規格、可觀測性與工具鏈的團隊；新專案可直接受益於 ESM 預設；仍在 CommonJS 的專案可先以升級指令試跑再決定時程。
第十二版沒有重新發明框架的抽象層，而是把長期累積的周邊議題一次收斂：套件格式、驗證規格、可觀測性與工具鏈。對已在維運的專案，升級的主要成本落在執行環境版本、測試框架與打包設定三處，升級指令能處理其中較機械的部分，但其餘仍需人工檢視。
對新專案而言，ESM 與 oxlint、Vitest、Rspack 的預設組合已接近目前 Node.js 生態的主流選擇，Standard Schema 亦讓驗證邏輯能沿用社群既有的函式庫。至於仍在觀望的團隊，可先以 nest upgrade --dry-run 檢視自身專案會產生的變更清單，再評估是否隨第九個修補版本一併推進。
