TypeScript类作类型、接口配合DI注入的开发实践规范咨询

直接将类作为类型使用是否属于不良实践？ #

不属于绝对的不良实践，但有明确的适用边界，不能一概而论：

• 简单场景下完全合法可用：如果是小型脚本、内部工具逻辑，某个类在全项目只有唯一实现，没有多态替换、单元测试mock的需求，直接用类作为类型标注是TS语言原生支持的用法——TS的类本身既充当构造函数的值，也充当实例的类型，这种写法没有任何语法问题，也不会造成维护负担。
• 高耦合需求场景下属于不好的实践：如果你的模块需要支持多实现替换、需要做单元测试mock、需要跨模块解耦，直接绑定具体类作为类型就会造成强耦合：此时类型校验会强依赖类的构造逻辑，哪怕你传入结构完全匹配的替代实现，只要不是该类new出来的实例就会报类型错误，把上层逻辑和底层具体实现死死绑在一起，后续迭代改造成本极高。

预定义接口+类实现+DI注入的模式是否属于良好实践？ #

这是TS中大型项目里经过广泛验证的优秀实践，尤其适配面向领域建模、依赖注入架构的项目，核心优势有三点：

• 解耦彻底：上层业务逻辑只依赖接口定义的能力契约，完全不感知底层具体实现，后续替换实现、增加代理逻辑、编写单元测试mock的时候，只要符合接口约定就可以无缝替换，不需要修改上层业务代码。
• 边界清晰：接口本身就是最准确的能力文档，开发者只需要看接口定义就能明确依赖的输入输出、公开方法，不需要翻遍具体类的实现代码梳理可用能力。
• 适配DI生态：NestJS、TSyringe等主流TS DI框架，核心设计逻辑就是「依赖令牌（接口/抽象类）+ 实现绑定 + 运行时注入实例」，这种写法和框架的设计思路完全契合，不会出现适配冲突。

参考示例 #

接口定义示例：

类实现接口示例：

补充提醒：不要教条式套用这套模式。如果是逻辑非常简单、确定不会有替换需求的场景，专门抽离接口反而会增加无意义的代码量，属于过度设计，直接用类做类型即可。

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