在 NestJS 中，模块的 exports 仅对其直接导入者生效；即使某模块（如 InfrastructureModule）被导入到 AppModule，其导出内容也不会自动“透传”给其他同级模块（如 PatientModule），必须显式导入才能使用。
在 nestjs 中，模块的 `exports` 仅对其直接导入者生效；即使某模块（如 `infrastructuremodule`）被导入到 `appmodule`，其导出内容也不会自动“透传”给其他同级模块（如 `patientmodule`），必须显式导入才能使用。
NestJS 的模块系统基于显式依赖声明，遵循严格的封装与作用域规则。一个模块通过 exports 列表公开的服务、提供者或子模块，仅对直接 import 它的模块可见——这与“全局注入”或“树形继承”无关。因此，尽管 InfrastructureModule 已被导入至 AppModule，但 PatientModule 和 RemsModule 作为与 AppModule 同级的独立模块（而非其子模块），无法自动访问 InfrastructureModule 导出的 FileStorage 或 RequestClient。
要解决您遇到的依赖解析错误：
ERROR [ExceptionHandler] Nest can't resolve dependencies of the PatientMedicalRecordFileRepository (ConfigService, ?). Please make sure that the argument FileStorage at index [1] is available in the RemsModule context.
您需要在实际使用这些服务的模块中显式导入 InfrastructureModule。例如：
// patient.module.ts
@Module({
imports: [
InfrastructureModule, // ✅ 显式导入，使 exports 可用
DatabaseModule, // 若需直接使用 DatabaseModule 的导出，也可一并导入
],
providers: [PatientMedicalRecordFileRepository],
controllers: [PatientController],
})
export class PatientModule {}同理，若 RemsModule 中也需要 FileStorage，也必须在其 @Module() 装饰器的 imports 数组中添加 InfrastructureModule：
// rems.module.ts
@Module({
imports: [InfrastructureModule], // ✅ 不可省略
providers: [RemsService],
})
export class RemsModule {}⚠️ 注意事项：
- exports 中的字符串令牌（如 'FileStorage'）必须与 @Inject() 中使用的键完全一致（大小写敏感）；
- DatabaseModule 在 InfrastructureModule.exports 中以模块形式导出，意味着其自身导出的所有提供者（如 TypeOrmModule 提供的 Connection）也将对导入 InfrastructureModule 的模块可用；
- 避免滥用 isGlobal: true 来“绕过”模块边界——它仅适用于 ConfigModule.forRoot() 等少数支持全局注册的模块，不能替代模块间依赖声明；
- 若多个业务模块均高频依赖 InfrastructureModule，可考虑将其设计为共享模块（Shared Module），但依然需每个消费者模块显式导入。
✅ 正确实践总结：
NestJS 的依赖图是静态可分析的。每个模块应明确声明其所需依赖——这不仅保障了 DI 容器的可靠性，也提升了代码的可维护性与可测试性。切勿假设“只要在 AppModule 导入就全局可用”，而应坚持“谁用谁导入”的原则。
