Angular依赖注入与模块化架构：从注入器层级到Standalone实战-开发者社区

开头部分：

如果你写过几年 Angular，大概率会有这种感觉：依赖注入（DI）和模块化架构并不是“懂不懂”的问题，而是“用得顺不顺手”的问题。同样是注册一个服务，有的人在模块里写个 providers 就完事了，有的人能把注入器层级、作用域隔离、树摇优化全盘纳入设计，后者写出来的系统在新增功能、替换实现、写单测时，明显轻松一个量级。这篇博文就是围绕 Angular 依赖注入系统与模块化架构这两个核心主题展开的，适合正在做中大型 Angular 项目的开发者，或者刚学完基础、想弄明白“为什么项目一复杂就用不下去”的人。

我会从依赖注入的底层设计讲起，再串起 NgModule 与 Standalone 两种模块化形态，最后给出一套可以直接落地的多模块业务注入方案，以及我这些年踩过的坑。内容不追求面面俱到，但每一处都尽量讲清楚“为什么这么设计”。

1. Angular 依赖注入：先理解它解决的根本问题

1.1 没有依赖注入的日子有多难受

你可能会问，不就是 new 一个服务吗？为什么 Angular 非要搞一套注入器出来？

打个比方：你买了个智能家居系统，如果每个房间都自己买一台路由器、自己接网线、自己维护配置，出了故障还得一间一间排查，这套系统很快会变成灾难。依赖注入做的事情就是“集中管理依赖的创建与传递”，组件不再负责 new 依赖，而是声明“我需要什么”，由注入器负责把对应的实例给到你。

在没有依赖注入的年代，一个 OrderService 里需要记录日志，你就得在构造函数里new LoggerService()；后来日志要换成文件输出，你改完 LoggerService 的构造函数，还要去把每一处 new 的地方翻出来改一遍。而 Angular 的做法是：

constructor(private logger: LoggerService) {}

组件只表达对 LoggerService 的依赖，至于它是从哪来的、怎么构造的、单例还是每次新建，全部交给注入器。这就是控制反转。它带来的直接收益是低耦合、易测试、易替换，间接收益是你可以通过配置在不同作用域里提供不同实现，而不需要改动业务代码。

1.2 注入器层级：这是 DI 系统最容易被低估的部分

Angular 的注入器不是只有一个，而是一棵树。从bootstrapApplication或NgModule启动时创建的环境级注入器，到懒加载模块自带的模块注入器，再到每个组件实例的组件注入器，层层嵌套。

理解层级重点是理解“查找规则”：当你在组件里注入某个服务时，Angular 会从当前组件注入器开始向上查找，直到找到对应的 provider；找不到就抛NullInjectorError。这个规则决定了服务的作用域：

放在providers里的组件级 provider，会为每个组件实例创建一个独立的注入器。
放在@Injectable({ providedIn: 'root' })里的服务，注册在根注入器，整个应用共享一个实例。
懒加载模块如果自己注入了服务，会创建一个新的模块注入器，挂在根注入器之下。

我见过不少项目把“所有服务都写成 providedIn: 'root'”，这在小型项目里问题不大，但一旦遇到需要给不同模块隔离状态的场景，就会发现自己被这种“全局单例”的惯性坑了。正确做法是先思考依赖的生命周期：这个状态是应用级的、模块级的，还是组件级的？然后选择对应的注入层级。

1.3 Provider 的五种写法，不只是 useClass

很多人以为 provider 就是{ provide: SomeService, useClass: SomeService }的简写，确实没错，但真正用开之后你会接触到更多变体。

useClass：让注入器用某个类来创建实例。最常见的场景是给抽象类提供具体实现。
useValue：直接提供一个已经创建好的对象或常量，适合配置项、全局标志、第三方库实例。
useFactory：通过工厂函数创建服务，适合需要根据运行时条件决定返回什么实例的场景。
useExisting：别名映射，让两个 token 指向同一个实例，比如接口收缩或者兼容老 token 的时候很好用。
providedIn: 'root'：服务元数据里直接注册，配合 tree-shakable 特性实现按需打包。

举个例子，你有一个 ConfigService，开发环境和生产环境要加载不同的配置，用useFactory最干净：

export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG'); export function configFactory(): AppConfig { return environment.production ? { apiBaseUrl: 'https://api.example.com', debug: false } : { apiBaseUrl: '/api', debug: true }; } // 在 providers 中注册 providers: [{ provide: APP_CONFIG, useFactory: configFactory }]

这里我刻意用了InjectionToken而不是字符串 token。记住：永远不要用字符串当 token，字符串容易命名冲突，而且没法支持类型推断。InjectionToken是带类型的，编译期就能发现问题。

2. 模块化架构：NgModule 走到 Standalone 的演进逻辑

2.1 NgModule 的职责边界

NgModule 看起来只是一个装饰器，但它的核心价值是“边界”。一个模块定义了三类东西：

declarations：这个模块拥有哪些组件、指令、管道。
imports：它依赖哪些其他模块的能力。
providers：这个模块范围内可注入的服务。

设计良好的 NgModule 应该遵循“按领域划分”的原则。一个商城项目，订单模块只管订单相关的组件、服务和 API，用户模块只管用户相关的东西。共享模块只承载一些纯 UI 组件和通用工具，核心模块只做应用初始化、全局异常处理这类事情。

但很多人把模块划分玩成了“文件夹分类”：把几个组件丢进一个模块，几个服务丢进另一个模块，然后互相 import，最后模块之间的依赖关系乱成一团。模块划分的核心是依赖方向要清晰，业务模块只能依赖共享模块，不能反过来。

2.2 懒加载与模块注入器的新生

路由懒加载是模块化架构最有价值的实战特性之一。用loadChildren配置子路由后，用户访问对应路由时 Angular 才会去加载该模块的代码，同时为该模块创建一个新的注入器。

这里的坑非常经典：如果在懒加载模块的 providers 里声明了某个服务，这个服务不会成为全局单例，而是“属于该懒加载模块的单例”。假设两个懒加载模块都各自注册了一份 ShoppingCartService，用户从一个模块跳到另一个模块时，购物车状态竟然不是同一个实例。

const routes: Routes = [ { path: 'orders', loadChildren: () => import('./orders/orders.module').then(m => m.OrdersModule) }, { path: 'cart', loadChildren: () => import('./cart/cart.module').then(m => m.CartModule) }, ];

如果你希望购物车状态是全局共享的，就应该把 ShoppingCartService 放进providedIn: 'root'，或者放到根模块 / AppModule 的 providers 里。反过来，如果你确实希望模块之间隔离状态，再考虑在模块级 providers 注册。

这其实引出一个设计原则：默认宁可把可复用服务做成 providedIn: 'root'，只有在明确需要模块隔离时，才把服务注册进模块 providers。但也要考虑 tree-shaking 的影响，后文会展开。

2.3 Standalone 组件：模块化不再是 NgModule 的专利

Angular 15 之后 Standalone 组件成了新常态。不再需要 NgModule 来包裹组件，组件自己通过 imports 声明需要的依赖。

@Component({ standalone: true, imports: [CommonModule, ReactiveFormsModule], providers: [], template: `...` }) export class OrderFormComponent {}

很多人以为 Standalone 就是“不用 NgModule”，其实它改变了模块化的组织形式：从“模块声明组件”变成了“组件声明自己的依赖”。这对依赖注入没有本质改变，注入器树依然存在，只不过模块注入器的来源从 NgModule 变成了路由懒加载的 standalone 组件集合。

如果你在存量项目里做迁移，我的建议是从最底层、最稳定的共享组件开始，一个个改成 standalone，再逐步把特性模块拆掉。不要试图一次重写，Angular 允许 NgModule 和 Standalone 共存，这个兼容期是很好的过渡窗口。

3. 实操：搭建一套多业务模块的依赖注入体系

3.1 场景设定与目录结构

假设现在要做一个商城后台，包含订单模块、用户模块和商品模块，各模块都有独立的 API 服务、状态管理，同时需要一个全局的日志服务和当前登录管理员信息服务。

项目结构大致如下：

src/app/ ├── core/ │ ├── services/ │ │ ├── logger.service.ts │ │ └── session.service.ts │ └── core.module.ts ├── shared/ │ ├── components/ │ └── shared.module.ts ├── features/ │ ├── orders/ │ │ ├── services/order-api.service.ts │ │ ├── pages/order-list/order-list.component.ts │ │ └── orders.module.ts │ ├── users/ │ │ └── users.module.ts │ └── products/ │ └── products.module.ts └── app.module.ts

core 模块只被 AppModule 加载一次，提供全局单例服务。shared 模块不提供任何服务，只导出通用组件，避免共享模块被多个懒加载模块引入后产生服务多实例的问题。

3.2 用 InjectionToken 定义服务边界

订单模块需要一个 API 服务，但这个服务的具体实现可能因为不同商家租户而不同。更合理的做法是先定义接口与 token：

export interface OrderApi { getOrder(id: string): Observable<OrderDetail>; saveOrder(order: OrderDraft): Observable<OrderResult>; } export const ORDER_API = new InjectionToken<OrderApi>('ORDER_API');

然后在订单模块里提供具体实现：

@NgModule({ declarations: [OrderListComponent], imports: [CommonModule, SharedModule], providers: [ { provide: ORDER_API, useClass: DefaultOrderApiService } ] }) export class OrdersModule {}

如果之后要接入新的第三方订单系统，只需要新增一个实现类，替换 provider 即可，业务组件一概不用改：

providers: [ { provide: ORDER_API, useClass: ThirdPartyOrderApiService } ]

这就是“面向接口编程 + 依赖注入”组合的经典收益。组件里只管@Inject(ORDER_API) private orderApi: OrderApi，具体来源是什么，完全由模块配置决定。

3.3 useFactory 根据不同环境动态装配

订单模块里有一类场景经常需要“动态选择数据源”：普通管理员走本地 API，对接外部 ERP 时走第三方网关。这个选择可以交给工厂函数：

export function orderApiFactory(http: HttpClient, config: AppConfig): OrderApi { if (config.orderApiMode === 'erp') { return new ErpOrderApiService(http, config.erpBaseUrl); } return new DefaultOrderApiService(http, config.apiBaseUrl); } providers: [ { provide: ORDER_API, useFactory: orderApiFactory, deps: [HttpClient, APP_CONFIG] } ]

注意deps是用来声明工厂函数参数依赖的，Angular 会按数组顺序把对应的实例传进来。漏掉 deps 是实战里常犯的低级错误，运行时会直接报Can't resolve all parameters for orderApiFactory。

3.4 路由级懒加载与独立注入器验证

让订单、用户、商品三个模块全部走懒加载：

const routes: Routes = [ { path: 'orders', loadChildren: () => import('./features/orders/orders.module').then(m => m.OrdersModule) }, { path: 'users', loadChildren: () => import('./features/users/users.module').then(m => m.UsersModule) }, { path: 'products', loadChildren: () => import('./features/products/products.module').then(m => m.ProductsModule) }, ];

此时每个模块都会在访问时创建一个新的模块注入器。你可以通过一个简单的日志服务来验证这一点：在服务构造函数里打印时间戳，分别在两个模块注入同一个 providedIn: 'root' 的服务和模块 providers 里注册的服务，观察实例创建次数。

我实测的结论很直接：providedIn: 'root'的服务只在应用启动时创建一次；模块 providers 里的服务在每次进入该模块时，如果之前没有该模块注入器的实例，就会新建。如果你在根模块 providers 和懒加载模块 providers 里同时注册了同一个 token，那么会存在两个实例，具体注入到哪个取决于注入点位置，非常容易踩坑。

3.5 组件级 provider 的局部状态管理

表单类的组件经常需要局部状态。例如订单筛选面板，每个组件实例都要有自己的筛选状态，此时组件级 provider 是最合适的选择：

@Component({ selector: 'app-order-filter', templateUrl: './order-filter.component.html', providers: [FilterStateService] }) export class OrderFilterComponent { constructor(private filterState: FilterStateService) {} }

这里的 FilterStateService 没有在任何模块里注册，也没有 providedIn: 'root'，但它能正常工作，因为 Angular 会在创建组件时新建一个注入器，并在这个注入器内注册该服务。多个 OrderFilterComponent 就会有多个 FilterStateService 实例，互不干扰。

需要留意的坑是：如果 FilterStateService 自己又注入了其他全局服务，Angular 会先向上查找那些依赖，再把它们注入进来。组件级 provider 只是限制了 FilterStateService 的生命周期范围，并不会切断它跟全局服务的联系。

4. 日常踩坑记录：依赖注入与模块化架构的高频问题

4.1 NullInjectorError 为什么会找上门？

NullInjectorError: No provider for OrderApiService应该是 DI 报错里出现频率最高的一个。

典型原因有三类：第一，服务确实没有在任何地方注册，解决方法是在@Injectable({ providedIn: 'root' })加上或加入模块 providers；第二，服务所在的模块被懒加载，但你把这个服务注册到了另一个不相关的模块里，解决办法是确认注入点所在模块的注入器可见范围；第三，你在组件里注入一个来自子模块的服务，但组件和该服务不在同一个模块的依赖范围内。

排查这类问题，我有个习惯：先看报错里的注入点，然后顺着组件所在的模块往上找 providers 链。90% 的情况是“服务注册的位置和注入的位置不在同一条注入器链路上”。

4.2 循环依赖：Angular 的递归陷阱

依赖注入的循环依赖通常表现为类似这样的错误：

Circular dependency in DI detected: OrderApiService -> HttpLoggingService -> OrderApiService

A 服务需要 B 服务，B 服务又需要 A 服务，注入器没法决定谁先创建谁。解决办法有几个方向：

用forwardRef(() => OrderApiService)包一层引用，让 Angular 延迟解析类型。
通过EventEmitter或Subject解耦两者之间的直接调用关系。
把一个服务内部的逻辑拆分到更底层的服务里，让 A 和 B 变成兄弟依赖。

我个人更推荐第三种方案，因为循环依赖往往是设计缺陷的信号，而不是写法问题。

4.3 字符串 Token 的隐患

在旧代码里偶尔会看到@Inject('apiService')这种写法，我强烈建议遇到就改成InjectionToken。

字符串 token 的问题是：不同模块可能无意中定义同名 token，Angular 不会报错，运行时却会注入错误的服务，而且这种错误极难排查。InjectionToken在编译期就具备类型约束，同样名字的 token 如果类型不同，你根本写不到一起。

4.4 懒加载模块里服务“丢单例”的经典案例

前面提到的购物车状态是典型例子。很多人以为只要在服务上标注 providedIn: 'root' 就不会有问题，但如果你写的服务是“模块级 providers + 懒加载模块”的组合，就一定要意识到：每次懒加载模块代码加载后创建的模块注入器，与启动时创建的根注入器不是同一棵树上的同一个点。

这个坑不好排查，因为逻辑上服务代码完全一样，状态却不对。我会在根模块的 providers 和懒加载模块的 providers 里同时注册同一个服务，然后观察实例变化，用日志确认。

4.5 树摇优化不生效？想想你的 provider 写在哪

Angular 的 tree-shakable DI 依赖一个前提：服务是通过@Injectable({ providedIn: 'root' })注册的。如果服务写在模块的 providers 数组里，即使这个模块没被任何地方使用，只要模块被引入，服务也会被打包进去。

对中大型项目来说，全局模块 providers 里堆积的未使用服务是体积增长的一大来源。我在项目里做过一次统计：把一批只在某个角落使用过一次的服务从模块 providers 改为 providedIn: 'root'，构建产物减少了接近 100KB（gzip 前）。背后的逻辑是，providedIn: 'root'让 Angular 编译器知道这个服务可以按需生成 factory，没有被引用时直接丢弃。

4.6 APP_INITIALIZER：应用启动前的依赖注入

有些服务需要在应用启动前就完成初始化，比如拉取用户信息、加载远程配置。Angular 提供了APP_INITIALIZER这个注入 token：

export function initializeApp(configService: ConfigService) { return () => configService.load().pipe(map(config => config)).toPromise(); } providers: [ { provide: APP_INITIALIZER, useFactory: initializeApp, deps: [ConfigService], multi: true } ]

multi: true是关键，没有它，后注册的初始化函数会覆盖前面的。使用 APP_INITIALIZER 时要注意：它必须返回 Promise 或 Observable，并且直到 resolve 前应用不会渲染。如果初始化逻辑依赖后端接口，要设置好超时和错误兜底，否则后端一挂，前端白屏一片。

4.7 测试里的依赖注入替换技巧

写单元测试时，依赖注入的价值体现得非常到位。你可以用TestBed.configureTestingModule来覆盖掉真实服务：

TestBed.configureTestingModule({ providers: [ { provide: ORDER_API, useClass: MockOrderApiService } ] });

测试里不会发起真实 HTTP 请求，也不依赖后端状态，只需要给 token 提供一个 mock 实现。这比 mocking 一个类的静态方法要优雅得多，因为被测组件完全感知不到差异。

4.8 forwardRef 的正确使用姿势

forwardRef常见于相互引用的组件或指令，以及一些复杂的服务依赖关系。使用方法是：

@Injectable() export class ParentService { constructor(@Inject(forwardRef(() => ChildService)) private child: ChildService) {} }

但不要一来就上 forwardRef，它只是绕过了编译器的立即解析限制，运行时的循环依赖依然可能存在。先重构代码，把环拆掉，比用 forwardRef 掩盖问题更重要。

4.9 provideIn: 'root' 与模块隔离的取舍

最后再聊一下设计层面的取舍。providedIn: 'root'是省事、树摇友好、测试友好的默认选择，但它会让服务的状态全局共享。我遇到过把用户当前选中的订单状态放到全局 root 服务里，导致切到用户模块后还残留上一个登录用户数据的案例。

解决办法是任何时候都问自己：这个状态的生命周期是什么？

如果跟整个应用一样长，用 providedIn: 'root'。
如果跟某个路由模块一样长，注册到该模块的 providers。
如果跟某个组件一样长，注册到组件 providers。

依赖注入系统的核心其实是“作用域管理”。把服务的注册位置和生命周期绑定起来，整个系统的边界就清晰了。

4.10 额外一个小建议：把 DI 配置集中到显眼的稳定文件

实战里我踩过这样一个坑：团队成员为了方便，随手把服务注册到了某几个组件的 providers 里，导致后来排查一个问题时，怎么也想不通“为什么这段代码在两个页面行为不一样”。后来我总结出一个习惯：把核心服务的 provider 配置集中写在模块的 providers 数组或独立的di-config.ts文件里，组件内尽可能只写@Inject(Token)，不要在组件 providers 里堆太多业务服务。默认这样做，至少能减少一半的“玄学问题”。

结尾

依赖注入和模块化架构在 Angular 里是一对双生子，搞懂一个另一个也会顺理成章。我用下来最深的体会是：依赖注入的难点不在于概念，而在于根据实际业务场景选择正确的提供层级和模块边界，这需要你在真实项目里反复权衡。顺手放下一个判断标准——如果团队里的新人能在不看文档的情况下，根据代码结构猜出某个服务应该在哪个层面注册，你的架构就是成功的；反之，如果连你自己都说不清某个 provider 是从哪里冒出来的，那就要重新审视了。

如果你正准备给自己的 Angular 项目做一次依赖梳理，从最常用的服务入手，逐个检查它的注册层级，再配合懒加载模块的注入器分析，很快就能找到值得改进的地方。这套方法论不会让你的代码瞬间变成教科书，但至少能少踩几个我踩过的坑。