NestJS 12版本聚焦核心架构升级，涵盖多项关键改进。其核心革新在于将核心包迁移至ESM格式，此举极大简化了团队适配流程，符合官方发布的路线图，相关公告获得广泛关注。同时新增的标准Schema验证功能成为重要亮点，支持更灵活的路由装饰器配置，并引入原生可观测性SDK，丰富了后端监控能力。该版本正是对工具链与配置状态的一次系统清理，虽未在性能层面实现突破，但带来可观测性和验证能力的显著提升。迁移至ESM后，CommonJS应用仍可通过Node.js的require(esm)特性兼容运行，这一适配要求与Node.js 20.19+或22.12+的版本限制直接相关。在项目构建方面，nest new生成项目时会提供CJS或ESM选择，且Rspack取代webpack成为单仓库打包器，ESM项目默认集成Vitest与oxlint。开发者通过基准测试发现，ESM在启动速度与内存占用上无显著优势，相关评测强调这是工具链与配置的全面优化，而非性能升级。验证能力变化最为突出，基于标准模式的装饰器支持更广泛的配置对象，使得Zod、Valibot等校验库无需额外封装即可顺畅集成，class-validator仍保留默认选项。此外，@nestjs/observe新增instrument选项，以控制器与提供者为单位监测生命周期信息，但存在供应商锁定风险。nest deploy命令转向Mau平台，新增版本还强化安全能力，但部分用户反馈ESM下路径别名与Fastify中间件存在兼容问题。整体而言，NestJS 12在架构标准化、可观测性与工具链优化上取得显著进展，后续版本将持续迭代完善兼容性与可靠性。
--91likeyou---
class-validator 仍然是文档中记录的默认选项。博主 iiaku 认为，基于规范而非直接基于 Zod 进行开发“既能保留选择权，又能消除冗余代码”。不过，在 ByteIota 的预览报道下面，有评论者指出，由于 Nest 仍然依赖于旧版 TypeScript 装饰器，所以类型仍然需要手动注解。
在新增的功能中，争议最大的是 @nestjs/observe。它通过一个新增的 instrument 选项挂接到 Nest 自身的生命周期中而非对 HTTP 服务器进行修补，并以控制器和提供者为单位报告跟踪信息。APM 供应商 Scout Monitoring 承认，该功能提供了更丰富的上下文信息，但同时也警告称，该 SDK“仅限 NestJS”，未提供开箱即用的跨栈关联功能，而且“在框架层面存在陷入供应商锁定”的风险。一个新增的 nest deploy 命令（转发至 Mau 平台）也同样指向了第一方服务。
从 v11 升级意味着需要通过 npm i -g @nestjs/cli@latest 安装最新的 CLI，并运行 nest upgrade 命令。该操作会将所有的 @nestjs/* 包升级至 v12，将 TypeScript 升级至 v6，并应用一些技术性变更，例如将 GraphQL Playground 切换为 GraphiQL，以及替换为 NATS v3 客户端。
该操作刻意没有将项目转换为 ESM、Vitest 或 oxlint。要了解其余内容，包括生命周期钩子的顺序以及 Joi v18，请查阅迁移指南。
一个 GitHub 问题驱动文档指出，AWS Lambda 运行时需要 --experimental-require-module 参数，而其他用户则报告称，在 ESM 环境下路径别名无法正常工作，而且 Fastify 中间件会异常卡死。随后的 v12.1 版本已经新增了内置的 Cookie、CSRF 保护和安全响应头。
NestJS 是一个采用 MIT 许可的开源框架，用于使用 TypeScript 构建高效且可扩展的服务器端应用程序。它结合了受 Angular 启发的模块和依赖注入架构，并支持 Express 和 Fastify，在 GitHub 上拥有超过 7.6 万个星标。
：
🔥 热词：#ESM · #12 · #Node · #js · #NestJS · #包、标准模式验证和原生可观测性 · #用于构建服务器端 · #应用程序的