NestJS项目中TypeORM自定义仓储导入与注入异常原因咨询

一、TypeScript 元数据反射规则触发的注入失效 #

核心规则：TS 开启emitDecoratorMetadata配置后，只有当类、类方法、构造函数或构造参数上存在至少一个装饰器时，编译器才会为构造函数生成design:paramtypes类型元数据。缺少触发条件时，Nest 无法获取构造参数的类型信息，也就没办法匹配对应的注入令牌完成依赖注入。

对应你的场景1现象：

• 原配置中第二个构造参数带有@InjectRepository(Login)装饰器，触发了整个构造函数的元数据生成流程，两个参数的类型信息能被Nest正常读取，因此可以从模块容器中匹配到对应Provider完成注入。
• 一旦移除该参数上的装饰器，整个LoginService的构造参数上没有任何装饰器，TS不会生成任何参数类型元数据，Nest解析依赖时拿不到两个参数对应的匹配令牌，最终注入的两个仓储实例都是undefined，访问实例上的方法自然抛出属性不存在的错误。

二、@InjectRepository装饰器的令牌匹配错位 #

装饰器的实际作用：@InjectRepository并非标记要注入自定义仓储类，而是生成对应实体的标准Repository实例的注入令牌，用于从容器中匹配该令牌对应的Provider。

当前配置存在两个令牌不匹配的问题：

• SecurityModule中TypeOrmModule.forFeature([PasswordRepository, LoginRepository])的写法，本质是把两个自定义仓储类本身作为Provider注册到当前模块，使用的注入令牌就是自定义仓储类本身，容器中没有匹配@InjectRepository生成的标准Repository令牌的Provider。
• 当你给第一个构造参数加上@InjectRepository(Password)时，Nest会切换为用标准Repository的注入令牌去当前模块的容器里查找对应Provider，由于令牌不匹配无法找到对应实例，自然就会抛出依赖解析错误，也就是你看到的Nest can't resolve dependencies of the LoginService...报错。报错中标记的?就是切换令牌后无法匹配到Provider的位置。

三、模块依赖共享的结构性配置问题 #

当前模块设计存在边界规则不严谨的问题，是后续引发同类异常的潜在根源：

• DalModule虽然把两个自定义仓储列为内部Provider，但没有通过exports字段导出这些Provider，就算SecurityModule直接import了DalModule，也根本无法访问到DalModule上下文中的仓储实例。目前SecurityModule能正常注入仓储，完全是因为自己在forFeature中重复注册了一遍相同的仓储类，绕开了Nest模块的共享边界规则。
• DalModule中的TypeOrmModule.forFeature([Entity1, Entity2, Entity3])没有关联Login、Password两个实体，就算后续把自定义仓储从DalModule导出，实例化仓储时也会因为缺少关联的实体仓储依赖初始化失败——毕竟你的自定义仓储继承自AbstractRepository，必须依赖对应实体的标准Repository实例才能完成正常初始化。

内容的提问来源于stack exchange，提问作者Dondey