2026年了，Angular 里在懒加载模块改了登录态，回到首页怎么还是旧值？

在懒加载模块里改了登录态，回到首页读到的还是旧值，多数不是接口或状态库的问题，而是同一个服务被提供了两遍：懒加载模块会创建自己的子注入器，在那里又写了一次 providers，于是它拿到的是模块作用域的新实例，根注入器里那份不会自动共享。2026 年交付中，这类现象常出现在登录态、全局配置和跨模块缓存上。先核对提供位置，通常比改业务代码更快定位；多数情况删掉重复提供即可，少数确实需要模块隔离的场景则应显式保留并写清边界。

先搞清楚 Angular 的注入器是分层找服务的

Angular 的依赖注入不是全应用只有一份实例，而是按注入器层级从下往上查找。默认情况下 providedIn: 'root' 的服务注册在根注入器上，在整个应用内通常是单例；但进入懒加载模块后，模块会创建自己的子注入器，查找服务时先看自己的 providers，命中就不再往上找。

所以判断两个地方拿到的是不是同一份实例，看的是提供位置，不是类名。同名不代表同源，写在不同的注入器里就是两份，改其中一份，另一份不会跟着动。

• 根注入器：providedIn: 'root'，或根模块与应用启动配置里提供的服务，通常全应用共享。
• 模块注入器：懒加载路由对应模块自己的 providers，只在该模块及其子组件内可见。
• 组件注入器：组件级 providers，只在该组件及其子组件内有效，组件销毁后实例也一起销毁。

2026 年独立组件和独立 API 用得更多，提供位置比早期写法更显式，但层级的判断逻辑没变：越靠近使用方提供的，越容易生成一份局部实例。

为什么懒加载模块会“多出”一个服务实例

懒加载模块在首次加载时才创建自己的注入器。如果在它的 providers 里又写了一遍同一个服务，Angular 会认为这个模块需要自己的实例，子注入器就新建一份。结果是在懒加载模块里改状态，根组件读不到；根组件改了状态，懒加载模块里也不跟着变。

这类问题在联调时比较隐蔽，编译不报错，类型检查也正常。常见现象是登录态在某个二级模块里失效、全局配置在懒加载页面读到旧值，容易被误判成接口缓存、状态管理库用错或者时序问题，方向一偏就多花半天甚至更久。

还有一种相邻情况要分开看：服务本身只有一份，但懒加载模块在拿到实例之前就把值读进了组件字段，等实例更新时组件没有重新取值。这不是多实例，而是读取时机的问题，改法也不同——前者改提供位置，后者改订阅或取值方式。建议的顺序是先查实例，再查时机。

三步核对：先定位，再动代码

按 2026 年项目交付的习惯顺序，遇到两边数据不一致可以先走这三步，避免一上来就换架构。

1. 查声明：全局搜索这个服务的类名，看它出现在哪些 providers 里，重点看懒加载路由对应的模块，不要只搜当前打开的文件。
2. 查实例：在服务构造函数里打一个实例标记（时间戳或自增计数都可以），分别在根组件和懒加载模块里注入并对比，标记不同基本可以判定是多实例。
3. 查时机：确认懒加载模块的加载与预加载策略，看看是不是加载顺序叠加多实例，一起造成了“读到旧值”。

注意两点：实例标记不要留在生产构建里；第三步要连同预加载策略一起看，否则容易把时机问题当成实例问题，改错地方。

确认之后怎么改：几种常见做法对比

确认是多实例后，改法取决于业务是否需要独立实例。要全局共享就删掉重复提供，要模块隔离就显式写在模块上并给出清晰边界。下面几种是交付中比较常见的做法，改动量和回归时间给的是经验区间，具体还看项目规模和调用面。

• 做法一：只在根提供，移除懒加载模块里的 providers。适合登录态、全局配置、跨模块缓存这类要单例的服务；改动量小，经验区间大约 0.5 到 2 小时可完成并回归。
• 做法二：配置类服务用模块提供的约定放在根侧，懒加载模块只导入模块、不重复提供。适合带初始化参数的服务；经验区间大约 2 到 6 小时，视配置项多少而定。
• 做法三：保留懒加载模块独立 providers，用命名或组件级提供划清隔离边界。适合多租户、按模块独立缓存的场景；成本取决于调用面，经验区间大约 1 到 3 天。
• 做法四：引入状态管理库统一管理。适合状态复杂、多人协作的中大型项目；引入和迁移成本较高，常见区间 1 到 2 周，小项目通常不必上。

对比的落点不是哪种更“先进”，而是状态的共享范围有没有写清楚。拿不准时先按做法一回退到单例，再按业务需要逐步隔离，比一开始就上重型方案更容易控住回归面。

什么情况下确实该保留两个实例

不是所有重复实例都是问题。有些场景确实需要每个模块各持一份状态，比如按租户隔离的本地缓存、按模块独立计算的临时数据、只服务某个页面的表单草稿。这时候要做的是把边界写进代码，而不是让它碰巧发生。

• 值得做：在该模块或该组件上显式提供，并在注释里写明“这里需要模块级实例”，方便后来人判断。
• 值得做：把共享的部分抽到根提供的服务里，把隔离的部分留给模块，两层职责分开。
• 不建议：靠“在别处再 provide 一次”来实现隔离，读代码的人很难看出意图，后续接手容易误删。

上线联调现场：一次重复提供带来的返工

比较常见的约束是这样：迭代周期只有三四周，前端两个人分工，接口契约还在改。做法是各写各的模块，登录态服务在根提供过一次，订单懒加载模块为了省事又在 providers 里提供了一次。联调时订单模块拿到的用户 ID 一直是初始值，排查了大半天才定位到重复提供。代价是改了三个模块的导入和一处调用，还补了一轮回归，占掉一到两天联调窗口。

按经验区间，如果一开始就把提供位置统一在根，通常能省下几小时到一两天不等的排查与返工时间。先核对提供位置，再写业务逻辑，比事后定位划算。

适用场景与边界

Angular 的层级注入本身是为了模块化隔离服务，它不是问题来源，随手多写一遍 providers 才是。判断标准可以简化成一句：这个状态需不需要跨模块一起变？需要就在根提供，不需要就明确写在模块或组件上。

• 适合按根提供：登录态、权限信息、全局配置、跨模块缓存，这类重复提供一般就是坑。
• 适合按模块提供：多租户缓存、按模块隔离的临时数据，但要显式写清边界。
• 不适合：把服务全部堆在根注入器。启动体积和初始化成本会上来，按需懒加载的服务仍应跟随模块。
• 不适合：为了让测试跑通而顺手再提供一次，测试环境和线上行为容易不一致，之后更难查。

边界句：要全局共享就别在懒加载模块重复提供；要模块隔离就明明白白写在该模块，不要靠碰巧拿到一份错误实例。

常见问题

Angular 的服务默认是单例吗？

providedIn: 'root' 的服务在根注入器内通常是单例；但懒加载模块若又提供一次，它在该模块作用域里会是另一个实例。

怎么判断我遇到的是不是多实例问题？

在服务构造函数里打一个实例标记，分别从根组件和懒加载模块注入对比，标记不同基本可判定为多实例，再去核对 providers 写在哪。

把懒加载模块里的 providers 删掉就没问题了吗？

多数情况可以；如果这个服务需要模块级初始化配置，配置一般留在根侧提供，懒加载模块只导入模块、不重复提供，具体以官方文档为准。

组件级 providers 也会产生新实例吗？

会，组件级提供的服务只在该组件及其子组件内有效，离开组件树就销毁；适合局部状态，不适合登录态这类要跨页面共享的数据。

服务只有一份，值却还是旧的，也要先查提供位置吗？

不一定要先查，这种情况多半是读取时机或订阅方式的问题：实例更新了但组件没重新取值，可以先核对取值和订阅写在哪。

行动指引：先全局搜索服务的提供位置，确认是根提供还是模块提供；需要全局共享就保留根提供、移除重复项，需要隔离就写明模块边界。适用边界：这套判断适合常规 Angular 项目；若已经引入状态管理库，仍要保证服务提供层级和状态源一致，避免两套状态各走各的。