NestJS + TypeORM注入仓库的最佳实践：为何优先使用@InjectRepository而非通过Connection获取自定义仓库？

这是个非常好的问题！两种方式确实都能获取到仓库实例，但在绝大多数业务场景下，我们更推荐用@InjectRepository的方式，核心原因如下：

• 贴合依赖注入（DI）的设计理念
  NestJS的核心就是依赖注入，@InjectRepository是显式声明服务对仓库的依赖，让Nest的DI容器自动帮你管理仓库的实例化、生命周期和依赖关系。而手动通过connection.getCustomRepository获取的话，相当于你绕过了DI容器自己处理依赖，会破坏代码的解耦性——后续如果要替换仓库实现（比如换成Mock版本），会变得非常麻烦。

• 模块边界更清晰，维护性更强
  使用TypeOrm.forFeature([ARepo])把仓库和对应的模块绑定，明确了这个仓库属于AModule的职责范围。其他模块如果需要用到ARepo，要么导入AModule，要么在自己的模块里注册TypeOrm.forFeature([ARepo])，这种方式让模块的依赖关系一目了然，避免了全局随意获取仓库导致的依赖混乱，大型项目里这点尤其重要。

• 单元测试成本更低
  写单元测试时，@InjectRepository的方式可以轻松替换仓库实例：

  const moduleFixture = await Test.createTestingModule({
    providers: [
      AService,
      { provide: getRepositoryToken(ARepo), useValue: mockARepo }, // 直接替换Mock仓库
    ],
  }).compile();
  

  但如果是手动从Connection获取仓库，你得Mock整个Connection对象，还要确保getCustomRepository返回的是Mock实例，测试的复杂度会高很多。

• 更好地兼容NestJS+TypeORM的生态特性
  Nest的TypeORM模块提供了很多开箱即用的特性，比如事务装饰器@Transaction()、仓库的生命周期管理、多数据库连接支持等，这些特性都是基于通过TypeOrm.forFeature注册的仓库来实现的。手动获取的仓库可能无法无缝享受到这些便捷能力，比如在事务中自动使用当前事务的连接实例。

• 多数据库场景下更可靠
  如果你的应用需要连接多个数据库，@InjectRepository可以通过指定连接名称精准注入对应仓库：

  constructor(
    @InjectRepository(ARepo, 'secondary-connection') private aRepo: ARepo
  ) {}
  

  而手动获取的话，你得先确保拿到的是正确的Connection实例，很容易因为疏忽用错连接，引发数据错误。

当然，第二种方式也不是完全没用——比如在需要动态切换不同仓库的特殊场景下，手动获取会更灵活。但对于绝大多数常规业务开发来说，@InjectRepository的方式更符合NestJS的设计规范，代码也更易维护、测试和扩展。

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