前言

刚用 nest new 初始化的项目，AppModule 往往只有十几行。但随着项目走向生产环境，根模块会迅速演变成一个高危的“巨石文件”：

Day 1:   引入 ConfigModule 读取配置
Day 7:   引入 LoggerModule (Pino/Winston) 替换默认日志，带上一长串 Transport
Day 15:  引入 PrismaModule / TypeOrmModule.forRootAsync() 连接数据库
Day 30:  引入 Redis / BullModule 连接队列
Day 60:  注册 APP_GUARD, APP_INTERCEPTOR, APP_PIPE, APP_FILTER 增强器
Day 120: 加入 20+ 个业务模块 (User, Order, Payment, Product...)

最终的 AppModule 会带来三大工程隐患：

// 典型失控的 app.module.ts
@Module({
  imports: [
    // 基础设施 1：环境配置 + 校验
    ConfigModule.forRoot({ isGlobal: true, validate: validateEnv }),
    // 基础设施 2：日志异步工厂
    LoggerModule.forRootAsync({ useFactory: (cfg: ConfigService) => ({ ... }) }),
    // 基础设施 3：持久层与缓存
    PrismaModule,
    RedisModule.forRoot({ ... }),
    ScheduleModule.forRoot(),
    // 基础设施 4：跨切面鉴权基础
    JwtModule.registerAsync({ ... }),

    // 业务模块（被淹没在配置细节的汪洋大海中）
    UserModule,
    OrderModule,
    PaymentModule,
    InventoryModule,
    NotificationModule,
    // ... 更多业务模块
  ],
  providers: [
    // 全局增强器与一堆未解耦的 Provider
    { provide: APP_GUARD, useClass: JwtAuthGuard },
    { provide: APP_INTERCEPTOR, useClass: ResponseTransformInterceptor },
    { provide: APP_PIPE, useValue: new ValidationPipe({ transform: true, whitelist: true }) },
    { provide: APP_FILTER, useClass: GlobalExceptionsFilter },
  ],
})
export class AppModule {}

1. 认知负载极高：想知道系统“包含哪些业务能力”，必须在几十行复杂的异步配置（useFactory、环境变量分支逻辑）中翻找。
2. 高频冲突与评审噪音：基础设施工程师（调日志级别、改数据库连接池）和业务工程师（增删业务模块）同时修改 app.module.ts，造成频繁的 Git 冲突和混杂的 Code Review 记录。
3. “全局单例”的脆弱性：ConfigModule.forRoot({ isGlobal: true })、ScheduleModule.forRoot() 这类“只能初始化一次”的模块，由于缺乏物理隔离，新人极易在其他子模块中重复 imports: [ConfigModule.forRoot()] 导致不可预期的状态重置。

---

此处内容已隐藏回复后方可阅读。