在NestJS中，模块的exports仅对其直接导入者生效；即使某模块（如InfrastructureModule）被导入到AppModule，其导出内容也不会自动“穿透”至其他同级模块（如PatientModule），必须显式导入才能使用。
在nestjs中，模块的exports仅对其直接导入者生效；即使某模块（如infrastructuremodule）被导入到appmodule，其导出内容也不会自动“穿透”至其他同级模块（如patientmodule），必须显式导入才能使用。
NestJS 的模块系统遵循显式依赖声明原则：一个模块要使用另一个模块导出的服务、控制器或提供者，必须在自己的 @Module() 装饰器中通过 imports 显式引入该模块。模块之间的依赖关系不会因共同挂载到 AppModule 而自动建立——AppModule 仅作为应用启动入口和顶层容器，不充当“依赖分发中心”。
例如，你定义了如下 InfrastructureModule：
@Module({
imports: [DatabaseModule],
providers: [
ConfigService,
{
provide: 'RequestClient',
useClass: AxiosRequestClient
},
{
provide: 'FileStorage',
useClass: S3FileStorage
}
],
exports: ['RequestClient', 'FileStorage', DatabaseModule]
})
export class InfrastructureModule {}虽然它被导入到了 AppModule，但 PatientModule 若想使用 @Inject('FileStorage')，必须自身导入 InfrastructureModule：
@Module({
imports: [
InfrastructureModule, // ✅ 关键：显式导入才能访问其 exports
// 其他依赖...
],
providers: [PatientMedicalRecordFileRepository],
controllers: [...]
})
export class PatientModule {}✅ 此时，PatientMedicalRecordFileRepository 中的构造函数注入才能成功：
constructor(
private readonly configService: ConfigService,
@Inject('FileStorage') private readonly fileStorage: IFileStorageService // ✅ 可解析
) { ... }⚠️ 常见误区与注意事项：
- ❌ 不要依赖“全局导入”：即使 InfrastructureModule 在 AppModule 中导入，PatientModule 仍无法隐式访问其导出项；
- ✅ 若多个模块都需要相同基础设施服务，可考虑将 InfrastructureModule 设为 全局模块（配合 @Global() 装饰器），但需谨慎使用——它会绕过模块边界，降低可测试性与可维护性；
- ✅ 推荐做法：保持模块自治，按需导入。这使依赖关系清晰、单元测试隔离、代码演进可控；
- ? 报错提示
Nest can't resolve dependencies... in the RemsModule context正是 Nest 框架明确告诉你：RemsModule（或当前目标模块）上下文中未声明对 FileStorage 的依赖来源——解决方案永远是：检查并补全该模块自身的 imports 数组。
总结：NestJS 的 DI 容器作用域严格绑定于模块层级。导出（exports）定义“我能提供什么”，导入（imports）声明“我需要什么”——二者必须在同一模块声明中配对，才能完成依赖解析。 遵循这一原则，你的模块架构将更健壮、可预测且易于协作维护。
