angular 的依赖注入机制会自动解析服务构造函数所需的全部依赖，避免手动传参；而直接用 new 创建实例时，需自行提供所有构造参数，否则会报错。
angular 的依赖注入机制会自动解析服务构造函数所需的全部依赖，避免手动传参；而直接用 new 创建实例时，需自行提供所有构造参数，否则会报错。
在 Angular 中，当你写 new TranslateService() 时，TypeScript 编译器和运行时会严格检查其构造函数签名。如果 TranslateService 的构造函数声明了 9 个依赖参数（例如 private http: HttpClient, private parser: TranslationParser, private store: TranslateStore, ...），那么手动调用 new 就必须显式传入全部 9 个有效实例——这不仅繁琐，更违背了 Angular 的设计哲学。
而使用依赖注入（DI）时：
constructor(private translateService: TranslateService) { }
Angular 并未“跳过”这些参数，而是通过 Injector 系统自动完成以下流程：
- 静态分析：读取 TranslateService 构造函数的元数据（由 @Injectable() 装饰器和 TypeScript 的 emitDecoratorMetadata 支持）；
- 递归解析：对每个参数类型（如 HttpClient）查找已注册的提供者（Provider）；
- 实例化链：若依赖项自身也有依赖（如 HttpClient 依赖 HttpHandler），则递归构建完整依赖树；
- 注入创建：最终将所有解析出的实例按序传入 TranslateService 构造函数，返回一个完全初始化的服务实例。
✅ 正确做法：确保服务已通过模块或 providers 正确注册。例如，第三方 @ngx-translate/core 需调用：
@NgModule({
imports: [TranslateModule.forRoot()] // 在根模块注册，提供单例 TranslateService
})
export class AppModule { }
⚠️ 注意事项：
- 手动 new 实例会绕过 Angular 的 DI 生命周期（如 OnDestroy 不触发、无法注入其他服务）；
- 若服务依赖 @Optional() 或 @SkipSelf() 等修饰符，手动构造将无法体现这些语义；
- 即使是自定义服务，只要标记为 @Injectable()，就必须通过 DI 获取，而非 new。
总结：依赖注入不是“省略参数”，而是将参数解析与实例化委托给 Angular 的 Injector——它让复杂依赖关系变得可维护、可测试、可替换。坚持使用 constructor 注入，是拥抱 Angular 框架能力的关键实践。
