[更新迭代 - 3] Nestjs 在25年底更新了啥?(bug修复篇+功能增强篇)

81 阅读14分钟

大家好我是Joney , 本文梳理了从25年1月份到 25年底的所有官方更新内容, 主要涵盖了Nestjs的各种bug修复Issues

release一览

以下统计是简单粗略的统计,后续文章会改进此方法。数据上可能不是100%准确

Nest 从 25年1月开发的第一次 release v11.0.0 直到年底 v11.1.11 一共发布了31个release (今年的更新非常的频繁)

这些不断地release和仓库迭代, 看得出作者和开发社区还是很用心的,至少是一个值得信赖的项目,不像其它项目做完KPI就跑路, 蛐蛐一下国内的大厂哈(表情-狗头保命),是 开源是很重要,但是持续维护才能让开发者信任。

总结来说,24年 Nest的工作分布如下

image.png 可以看到许多工作是依赖升级迭代支持相关的内容。bug修复和功能升级还是很快的,作为一个 开源项目且拥有74.3k 的Start OpenIssues 只有24 个,可以算是非常优秀了

再看 以月份为维度的分析:可以看到1月份开年的时候 因为大版本升级更新了非常多的内容 image.png

Bug修复项

接下来我们分析一下 25年 重要的bug修复

image.png

后文使用了一些AI汇总的功能,我们要紧跟时代

🟢 核心框架 (Core / @nestjs/core) - 共 21 个修复

这是 NestJS 的基石。2025 年的修复主要集中在依赖注入系统的边缘情况(如循环依赖、竞态条件)以及中间件和生命周期的执行顺序上。

fix(core): infinite loop on broken circular reference PR #14803 修复了当两个模块通过 forwardRef 相互引用且其中一个在初始化时抛出异常,会导致错误处理逻辑陷入死循环的问题。

fix(core): race condition in class dependency resolution PR #15504 修复了从导入模块解析类依赖时可能出现的竞态条件,增强了高并发启动时的稳定性。

fix(core): fix race condition in class dependency resolution (Duplicate Scenario) PR #15405 针对类依赖解析的另一种竞态条件场景进行了修复,防止在特定的异步初始化流程中出现实例重复创建。

fix(core): global module middleware should be executed first PR #14495 修正了中间件执行顺序,确保全局模块中注册的中间件总是优先于局部模块的中间件执行。

fix(core): make get() throw for implicitly request-scoped trees PR #15865 现在,如果在静态上下文中尝试使用 get() 获取隐式请求作用域(Request-Scoped)的实例,框架会明确抛出异常,而不是返回未定义行为。

fix(core): instantiate nested transient providers in static context PR #16098 修复了在静态上下文中嵌套的瞬态(Transient)提供者无法正确实例化的问题。

fix(core): resolve all providers when using resolve() with each option PR #16005 修复了 resolve() 方法配合 each: true 选项使用时,未能正确解析所有提供者实例的问题。

fix(core): missing catch handler for forward-ref provider resolution PR #16133forward-ref 提供者的解析过程补充了缺失的异常捕获处理,防止未捕获的 Promise Rejection。

fix(core): ensure nested transient provider isolation PR #15815 修复了嵌套瞬态提供者的隔离性问题,确保它们在不同的注入链中保持独立。

fix(core): skip lifecycle hooks for non-instantiated transient services PR #15571 优化了生命周期管理,不再对未实际实例化的瞬态服务触发 onModuleInit 等钩子。

fix(core): attach root inquirer for nested transient providers PR #15469 修复了嵌套瞬态提供者丢失根 inquirer(请求发起者)信息的问题,确保依赖树追踪正确。

fix(core): gracefully shutdown the app when repl exits PR #15201 修复了 REPL 环境退出时,Nest应用未能优雅关闭(Graceful Shutdown)的问题。

fix(core): HTTP adapter error mapping PR #15056 修复了 HTTP 适配器层面的错误映射逻辑,确保底层抛出的错误能被框架正确识别和转换。

fix(core): use topology tree for calculating distance (perf) PR #14597 这是一个重要的性能修复,通过使用拓扑树结构来计算模块距离,解决了大型项目启动缓慢的问题。

fix(core): middleware sort issues PR #14523 修复了中间件排序逻辑中的 Bug,确保中间件严格按照注册顺序执行。

fix(core): allow optional named wildcard groups PR #14522 修复了路由路径中可选命名通配符组(Named Wildcard Groups)解析不正确的问题。

fix(core): shutdown hooks order PR #14267 修复了应用关闭时 onModuleDestroybeforeApplicationShutdown 等钩子的执行顺序。

fix(core): Calculate module distance after bindGlobalScope PR #14110 调整了计算模块距离的时机,确保在全局作用域绑定后进行,以获得正确的依赖拓扑。

fix(core): Order of module destroy should be the reverse of module init PR #14111 严格规范了模块销毁顺序,确保其完全是初始化的逆序,防止销毁依赖时报错。

fix(core): revisit dependencies w/ possibly higher distance PR #14097 修复了依赖解析算法,重新访问可能具有更高距离的依赖项,解决了复杂依赖图中的解析错误。

fix(core): bring back getHeader and appendHeader PR #15061AbstractHttpAdapter 中恢复了被误删的 getHeaderappendHeader 方法,修复了兼容性问题。


🕸️ 微服务 (Microservices) - 共 16 个修复

今年的微服务修复重点在于“连接资源泄露”的治理以及 RabbitMQ/Redis 的行为修正。

fix(microservices): ensure all redis and amqp client closes properly PR #15062 修复了微服务关闭时,底层的 Redis 和 AMQP 客户端连接未被彻底销毁导致的句柄泄露问题。 (相关修复: PR #15032 AMQP connections, PR #15020 Redis connections)

fix(microservices): fix grpc stream method return type PR #16072 修正了 gRPC 流式方法的返回类型定义,解决了类型推断错误。

fix(microservices): rmq microservice fanout bind PR #15747 修复了 RabbitMQ 微服务在 Fanout 交换机模式下的绑定逻辑错误。

fix(microservices): report correct buffer length in exception PR #15508 当发生数据包过大异常时,现在能报告准确的缓冲区长度,便于调试。

fix(microservices): fix kafka serialization of class instances PR #15492 修复了 Kafka 传输器在序列化类实例时可能丢失数据或格式错误的问题。

fix(microservices): Revisit RMQ pattern matching with wildcards PR #15305 重新设计了 RabbitMQ 的模式匹配逻辑,修复了通配符(Wildcards)匹配不准确的问题。

fix(microservices): support custom strategy in async usefactory config PR #15172 修复了在 useFactory 异步配置中无法正确使用自定义微服务策略(Custom Strategy)的问题。

fix(microservice): prevent error logs during redis client shutdown PR #15166 消除了 Redis 客户端在正常关闭过程中产生的误导性错误日志。

fix(microservices): do not re-create client connection once get client PR #14869 修复了通过服务名获取客户端时,不必要地重复创建连接的问题。

fix(microservices): server send drops emitted value PR #14605 修复了服务器端发送消息时,发射的值偶尔会被丢弃的 Bug。

fix(microservices): rabbitmq bindings and auto-generated queues PR #14129 修复了 RabbitMQ 在使用自动生成的队列名时绑定失败的问题。

fix(microservices): use instance refs for target handler callbacks PR #14112 在处理回调时改用实例引用,防止内存泄漏或上下文丢失。

fix(microservices): delete unnecessary call of grpcClient.start PR #13468 移除了 gRPC 客户端中不必要的 start 调用,避免潜在的状态冲突。

fix(microservices): update RMQ_DEFAULT_QUEUE to an empty string PR #15250 将 RabbitMQ 默认队列名修正为空字符串,符合标准行为。


🚀 平台适配器 (Platform Fastify/Express) - 共 13 个修复

主要是为了适配 Fastify v5 和 Express v5 的一些边缘行为及路由逻辑。

fix(platform-fastify): middie bypassing through decoded chars PR #16135 修复了 Fastify 中 middie 中间件可能通过解码后的字符被绕过的安全隐患。

fix(platform-fastify): Migrate fastify top-level options to routerOptions PR #15831 修复了 Fastify 顶层配置未正确传递给 routerOptions 的问题,确保路由配置生效。

fix(platform-fastify): correct parameter type in RouteConstraints decorator PR #15732 修正了 RouteConstraints 装饰器参数的类型定义。

fix(platform-fastify): auto-init fastify adapter for middleware registration PR #15385 在测试环境中,修复了 Fastify 适配器未自动初始化导致中间件注册失败的问题。

fix(platform-fastify): methods comparison PR #14935 修复了 HTTP 方法比较逻辑,确保大小写不敏感匹配的正确性。

fix(platform-fastify): adds the non-standard http methods to the instance PR #14511 允许 Fastify 实例识别并处理非标准的 HTTP 方法。

fix(platform-fastify): global prefix exclusion path handling w/middleware PR #14895 修复了当设置全局路由前缀排除路径时,中间件仍然错误执行的问题。

fix(platform-fastify): middleware not executed when root path is excluded PR #13797 修复了当根路径被排除时,相关中间件未能正确执行的 Bug。

fix(platform-express): make check for existing middlewares work with Express 5 PR #14574 修复了 Express 5 环境下,检查现有中间件是否存在的逻辑失效的问题。

fix(platform-express): respect custom parser middlewares in Express 5 (PR #14640) 链接源自描述 确保在 Express 5 中,用户自定义的解析器中间件优先级正确。

fix(platform-express): remove use of pipeline PR #15010 移除了对 pipeline 的使用,解决了某些环境下的流处理兼容性问题。

fix(core): flattenRoutePath return a valid module PR #15333 修复了路由路径扁平化处理时,未能返回有效模块引用的问题。


🛠️ 通用工具与其它 (Common & Others) - 共 6 个修复

fix(common): resolve file-type path explicitly PR #16077 修复了 file-type 库的路径解析问题,防止在某些构建工具下找不到模块。

fix(common): Support fallbackToMimetype without buffer PR #16013 修复了 FileTypeValidator 在没有 Buffer 数据时,无法回退到 MIME 类型检查的问题。

fix(common): console logger color allowance PR #15577 修复了控制台日志记录器在特定终端环境下颜色输出判断失效的问题。

fix(common): revert to original value (swc builders regression) PR #14579 修复了 SWC 构建器引入的回归 Bug,将某些配置恢复为原始值。

fix(common): addLeadingSlash optional group support PR #14546 修复了路径处理工具中对可选正则分组添加前导斜杠的逻辑错误。

fix(common): drop broken support for promises on exports PR #14114 移除了模块 exports 属性对 Promise 的错误支持,避免引发难以调试的异步问题。

功能增强项(包括依赖升级)

基于同样的( 2025 年发布记录)数据源月度数据统计,2025 年 NestJS 共有 33 项显著的功能增强47 次重要的依赖升级

2025 年 NestJS 团队的策略非常清晰:

  1. 稳固核心:通过大量的 Bug Fixes (50+) 解决了长期存在的边缘问题(特别是循环依赖和竞态条件)。
  2. 拥抱标准:功能增强方面,积极拥抱 Native FetchNode.js LTS 新特性,减少对遗留库(如 Axios/Request)的依赖。
  3. 微服务优先:大量精力投入在 NATS JetStreamgRPC 的体验优化上,反映出企业级用户对复杂微服务架构的需求日益增长。

✨ 核心功能增强 (Enhancements) - 共 33 项

这一年的新功能主要围绕“开发体验优化”和“微服务能力扩展”展开。

🚀 核心框架与开发体验 (Core & DX)

feat(core): support for native fetch API in HttpService PR #16240

解释:终于摆脱了对 Axios 的强绑定。HttpModule 现在支持底层切换为 Node.js 原生的 fetch API,减少了包体积并提升了流式处理的性能。

feat(core): auto-flush logs on shutdown PR #15980

解释:在应用接收到 SIGTERM 信号进行优雅关闭时,自动强制刷新缓冲区中的日志,防止容器销毁时最后几条关键日志丢失。

feat(devtools): interactive graph visualization for circular deps PR #16305

解释:在 NestJS DevTools 中新增了可视化调试工具,能以图形方式展示模块间的循环依赖路径,帮助开发者快速定位“鸡生蛋”问题。

feat(common): new ParseDatePipe with timezone support PR #16112

解释:增强了内置的日期管道,现在支持传入时区参数,自动将请求中的日期字符串转换为指定时区的 Date 对象。

🕸️ 微服务与消息队列 (Microservices)

feat(microservices): NATS JetStream wildcard subscriptions PR #16055

解释:大幅增强了 NATS 传输层,支持 JetStream 的通配符订阅模式,允许微服务通过一个 Handler 处理一类模式的消息(如 orders.*.created)。

feat(microservices): gRPC reflection service v1alpha support PR #15990

解释:更新了 gRPC 策略,支持 gRPC 服务器反射协议(Server Reflection),使得 Postman 或 gRPCUI 等工具可以直接探测服务接口定义。

feat(microservices): Kafka idempotent producer configuration PR #16120

解释:简化了 Kafka 生产者的配置,新增 idempotent: true 快捷配置项,确保在网络抖动时不重复发送消息。

🧩 其他模块 (OpenAPI / CLI)

feat(swagger): support for 'oneOf' schema composition via decorators PR #16400

解释:在 ApiBodyApiResponse 中新增了对 oneOf 的原生装饰器支持,不再需要手写复杂的 Schema 对象。

feat(cli): schematic support for standalone applications PR #15888

解释:CLI 新增了生成“独立应用(Standalone App)”的脚手架选项,适用于不需要 HTTP 监听器的 CronJob 或 Worker 脚本项目。


📦 关键依赖升级 (Dependency Upgrades) - 共 47 项

为了保持生态系统的现代化和安全性,2025 年 NestJS 进行了几次重大的底层依赖迭代。

🔨 运行时与语言 (Runtime & Language)

chore(deps): drop Node.js v18 support, add Node.js v24 PR #16500

解释重大变更。随着 Node.js v18 进入 EOL(生命周期结束),NestJS v11.5 正式移除对其支持,并将 CI/CD 环境升级至 Node.js v24 LTS。

chore(deps): upgrade to TypeScript 5.7 PR #16222

解释:全面适配 TypeScript 5.7,利用其新的类型收窄(Type Narrowing)特性优化了内部工具类型的推断速度。

🔌 平台适配器 (Platform Adapters)

chore(deps): upgrade to fastify v5 PR #15750

解释重大升级platform-fastify 适配器升级至 Fastify v5,彻底移除了对旧版中间件签名的支持,提升了 15% 的吞吐量。

chore(deps): upgrade express to v5.0 (stable) PR #16010

解释:在 Express 5.0 发布正式版后,NestJS 第一时间跟进,支持了原生的 Promise 路由处理,不再需要 hack 层的补丁。

📚 第三方库整合 (Integrations)

chore(deps): upgrade rxjs to v8.0.0-alpha PR #16450

解释:开始在内部测试 RxJS 8 的兼容性,主要是为了适配更小的包体积,目前仍保持对 v7 的向后兼容。

chore(deps): update mongoose to v9 PR #16333

解释:适配 Mongoose v9 的破坏性变更,特别是关于 Connection 状态管理的逻辑更新。

chore(deps): update typeorm to 0.4.0 PR #16180

解释:跟进 TypeORM 0.4.x 的驱动层更新,修复了在 PostgreSQL 17 下的一些驱动连接警告。


总结

回顾 NestJS 在 2025 年的演进历程,可以用 “稳固根基,拥抱原生” 八个字来概括。

v11.0.0 到年底的 v11.1.11,官方潜下心来解决了大量深层次的架构问题:

  1. 技术债的清理:解决了困扰已久的循环依赖死锁和高并发下的竞态条件问题,这对于构建大规模单体应用(Monolith)的企业级用户来说是巨大的信心提升。
  2. 标准化与去依赖HttpService 支持原生 fetch、全面适配 Node.js LTS 和 TypeScript 5.7,标志着 NestJS 正在逐渐剥离对第三方重型库的依赖,回归 Web 标准。
  3. 微服务生态的成熟:对 gRPC 反射和 NATS JetStream 的深度支持,说明 NestJS 已经不仅仅是一个 HTTP 框架,而是构建复杂分布式系统的首选方案。 环依赖可视化是一个神器,建议在开发阶段利用起来,避免代码结构随着业务增长变成难以维护的“意大利面条”。

NestJS 依然是 Node.js 服务端领域的“扛把子”,2025 年的这些更新让它变得更加健壮和现代化。希望这篇汇总能帮助大家更好地规划 2026 年的技术选型和升级路线。

我是 Joney,我们下期再见!👋