Angular 注入服务时在预期作用域找不到（Provider 作用域不匹配）怎么排查？

在 Angular 应用里调用 inject() 或构造函数注入时，如果某个服务在"按说应该有"的组件里却拿不到，运行时会抛出 NullInjectorError（提示 No provider for ...）。这类问题最常见的根因是 Provider 作用域不匹配：服务提供在了错误的注入器层级。本文基于 Angular 官方文档，给出从报错信息定位到修复验证的排查路径，适用对象是用 Angular 开发应用、遇到了"注入的服务在预期作用域找不到"这一具体现象的开发者。

先读报错：确认是"没提供"还是"提供错了地方"

出现 NullInjectorError 时，说明该 token 在组件能访问的所有注入器层级上都找不到 Provider。Angular 的解析顺序是自下而上、只查祖先、从不向下：

1. Element injector —— 当前组件或指令
2. Parent element injectors —— 沿 DOM 树向上经过父组件
3. Environment injector —— 路由或应用级注入器
4. NullInjector —— 仍未找到时抛出 NullInjectorError

报错信息中的依赖路径（dependency path）展示的是导致失败的注入链。文档给出的示例结果如下：

NullInjectorError: No provider for LoggerStore!
  Dependency path: App -> DataStore -> ApiClient -> LoggerStore

这条路径表示 App 注入了 DataStore，DataStore 注入了 ApiClient，而 ApiClient 尝试注入 LoggerStore 时找不到 Provider。排查应从链条末端（上例中的 LoggerStore）开始，先验证它本身的配置是否正确，再沿链向上核对每一环的 Provider 位置。

检查 Provider 声明位置：三个地方

确认 token 本身无误后，检查服务是否满足以下任一条件（文档给出的核对清单）：

• 服务带有 @Service() 装饰器；
• 服务带有 @Injectable({providedIn: 'root'})；
• 服务列在组件能够沿注入器层级向上触及的某个 providers 数组里。

三者都不满足，或者 Provider 所在的位置"够不着"，就是作用域不匹配。其中两类最典型的情形：

1. 提供在子组件的 providers 里。 服务写在某个组件的 providers 数组中时，实例只存在于该组件的注入器里，仅对这个组件及其子组件可用；父组件和兄弟组件用的是不同的注入器，拿不到。Angular 只向上查找，从不向下查找：

import {Component} from '@angular/core';
import {DataStore} from './data-store';

@Component({
  selector: 'app-child',
  template: '<p>Child</p>',
  providers: [DataStore], // Only available in this component and its children
})
export class ChildView {}

import {Component, inject} from '@angular/core';
import {DataStore} from './data-store';

@Component({
  selector: 'app-parent',
  template: '<app-child />',
})
export class ParentView {
  private dataService = inject(DataStore); // ERROR: Not available to parent
}

父组件注入子组件提供的服务必然失败。解决方案是把服务提升到更高层级（应用级或父组件）。若希望应用级可用并保留 tree-shaking，使用 @Service() 即可；如果不想默认全局可用，可指定 autoProvided: false（见 defining dependency providers 与 creating and using services）。

2. 提供在懒加载路由的 providers 里。 在懒加载路由的 providers 数组中提供服务的，Angular 会为该路由创建一个子 EnvironmentInjector，它和其中的服务只有在路由加载之后才存在。应用里急切加载（eager）部分的组件使用更早创建的注入器，访问不到这些服务：

import {Routes} from '@angular/router';
import {FeatureClient} from './feature-client';

export const featureRoutes: Routes = [
  {
    path: 'feature',
    providers: [FeatureClient],
    loadComponent: () => import('./feature-view'),
  },
];

import {Component, inject} from '@angular/core';
import {FeatureClient} from './feature-client';

@Component({
  selector: 'app-eager',
  template: '<p>Eager Component</p>',
})
export class EagerView {
  private featureService = inject(FeatureClient); // ERROR: Not available yet
}

对于需要跨懒加载边界共享的服务，改用 @Service()，使其在懒加载发生之前、所有地方都可用：

import {Service} from '@angular/core';

@Service()
export class FeatureClient {
  // Available everywhere, including before lazy load
}

如果服务确实应该懒加载，且只是个别急切组件可能访问不到，可以只在需要的地方注入，并用 optional 注入处理不可用的情况。另注意一个边界：默认情况下路由注入器及其服务在离开路由后依然保留，直到应用关闭才会销毁；如需自动清理未使用的路由注入器，参见 customizing route behavior。

还有一处容易被忽略的作用域差异：providers 对组件模板以及投影进来的内容（ng-content）都可见，而 viewProviders 只对组件自身模板可见，投影内容拿不到。如果你的服务"在父组件的 providers 里"却通过 viewProviders 声明，投影进该组件的子组件同样会注入失败——需要让投影内容访问服务时应改用 providers。

用 Angular DevTools 的 Injector Tree 查看层级

当仅凭代码读不出 Provider 在哪里时，用 Angular DevTools 的 Injector Tree（注入器树）检查。前提条件来自文档：

• 应用使用 Angular 17 或更高版本构建；
• 使用开发构建（ng serve 默认即是）；若调试已部署的应用，需关闭构建的 optimization（{"optimization": false}），生产构建会移除 DevTools 通信所需的功能。

打开浏览器 DevTools 的 "Angular" 标签，进入 Injector Tree 页签，可以看到 environment 与 element 两套注入器层级。选中出问题的组件注入器后：

• Is the service provided? 查看 Injector 区域中该服务是否出现；
• At what level? 沿组件树向上走，确认服务实际提供在哪一层（组件、路由还是应用级）；
• Multiple instances? 如果单例服务出现在多个组件注入器里，说明它被提供在了组件 providers 数组而不是 @Service / providedIn: 'root'，每个组件各有一份实例。

选中某个注入器后，DevTools 会高亮从该注入器到 root 的解析路径，包括元素注入器解析失败时跳转到哪个 environment 注入器；点击配置了 providers 的注入器，右侧会列出 token 及其类型，并可把 provider 打印到控制台。若服务在任何注入器中都看不到，说明它既没有 @Service() 装饰器，也没列在任何 providers 数组里。详见 devtools injectors 文档。

运行时验证可用性：optional 注入与构造器日志

DevTools 之外，文档给出了两种在运行时定位的手段。

用 optional 注入验证服务在当前注入器层级是否可用，不会让应用直接崩溃：

import {Component, inject} from '@angular/core';
import {UserClient} from './user-client';

@Component({
  selector: 'app-debug',
  template: '<p>Service available: {{serviceAvailable}}</p>',
})
export class DebugView {
  private userService = inject(UserClient, {optional: true});
  serviceAvailable = this.userService !== null;
}

optional 注入在找不到 Provider 时返回 null，据此可以判断"是完全没有提供，还是提供在了当前层级够不着的地方"。

再在服务构造器中打日志，确认实例化的时机与位置：

import {Service} from '@angular/core';

@Service()
export class UserClient {
  constructor() {
    console.log('UserClient created');
    console.trace(); // Shows call stack
  }

  getUser() {
    return {name: 'Alice'};
  }
}

服务创建时会看到日志消息和注入发生的调用栈。文档建议关注三点：构造器被调用了多少次（单例应为一次）、在代码的哪个位置被注入、是否在预期时间创建（应用启动时还是懒加载时）。

如果怀疑是 self / skipSelf 等 resolution modifier 改变了查找起点，可以用 optional 注入分别取值并比较实例，观察不同注入器层级上实际存在哪些实例；完整的解析规则见 hierarchical dependency injection 文档。

修复后如何验证

完成 Provider 调整（提升到父级组件或应用级、改用 @Service()、viewProviders 改回 providers 等）后，按以下方式确认：

1. 触发原本报错的组件，NullInjectorError 不再出现，注入得到实例；
2. 服务构造器日志按预期打印（单例服务只打印一次，且时机符合预期——启动时或懒加载时）；
3. 在 DevTools Injector Tree 中确认服务出现在预期的注入器层级，且不再在多个组件注入器中出现多份实例。

需要注意的边界：NullInjectorError 也可能是完全忘记 @Service / @Injectable() 装饰器、providedIn 未配置等原因导致，而非作用域问题；inject() 报错若提示 NG0203（not an injection context），则属于注入上下文问题而非作用域不匹配。这些情形以及 NG0200（循环依赖）、NG0204、NG0205、NG0207 等错误码的完整说明，参见 DI 调试与排查指南。