2026年了，Angular 里同一个详情页换了 id 内容没变，刷新一下又好了，是接口缓存吗？

在 Angular 项目里，从列表点进另一个详情页，地址栏参数变了、内容却没跟着变，多数不是接口缓存，而是同一条路由配置下组件实例被复用了：ngOnInit 只在首次进入时执行一次，snapshot 读到的仍是第一次进入时的参数。一个省时间的分流动作是手动刷新一次——刷新后就正常，基本可以按这条链路查。

地址变了内容没变，通常不是接口缓存

Angular 路由器在默认复用策略下，只要前后两次导航命中同一条路由配置（例如 /product/:id），框架会认为仍是同一个页面，于是不销毁旧组件、不重建新实例，只更新 ActivatedRoute 上的参数值。组件如果只在初始化时取一次参，之后再怎么点，读到的都是旧值。

区分清楚这一点很关键。不少团队的惯性反应是去查接口和浏览器缓存，联调时白等一轮；而只要确认是组件复用，改法就相当确定。

• ngOnInit 只跑一次：同一路由下参数变化不会触发新的初始化钩子，把数据加载全放在里面就会漏更新。
• snapshot 是取那一刻的值：route.snapshot.paramMap 在进入组件时读一次，之后不随参数变化。
• 刷新会重建：浏览器刷新等于重新进入应用，组件被重新创建，所以问题看起来消失了。
• query 参数同理：同一条路由只改 ?keyword=xx 也算同一路由，默认策略下同样复用组件。

一个动作就能初步分流

把页面手动刷新一次：刷新后内容正确，优先怀疑组件复用与取参方式；刷新后依旧不对，再往接口缓存、CDN 或服务端缓存方向查。这个动作在联调里省时间，也能避免前后端互相怀疑。

三步定位：路由层、生命周期层、数据源层

把排查顺序固定下来比逐个猜要快。这三层按顺序核对，不要跳步，跳步很容易出现误判——比如路由其实换了组件，却一直在改取参写法。

1. 路由层：先确认这次导航是否命中同一条带参数的路由配置，项目里有没有引入过自定义的 RouteReuseStrategy。合格标准是能直接说出是不是同一个组件实例。
2. 生命周期层：再看参数是在 ngOnInit 里用 snapshot 读的，还是以订阅 paramMap 的方式读的。前者只在进入时读一次，后者会随参数变化重复推送。
3. 数据源层：最后确认订阅到新参数后有没有真的重新请求。常见的短路逻辑是已有数据就直接 return，或者用了组件级临时缓存。

三层各有各的坑：路由层容易忽略 query 参数变化；生命周期层容易出现订阅写在构造函数里、脱离注入上下文的情况；数据源层容易把接口层缓存误当成组件缓存。三层核对完，基本能定位到具体是哪一段断掉了。

两种常见改法对比：订阅参数流还是让组件重建

2026 年常见做法主要落在两条路上，代价不同，不要默认挑改动面小的那条。

• 方案 A，订阅参数流：在 ngOnInit 里订阅 paramMap 或 queryParamMap，参数变化时重新取数。改动集中在页面内部，组件实例保留，滚动位置与部分状态不丢。要注意订阅释放时机，较新版本可用 takeUntilDestroyed 这类写法收口。
• 方案 B，参数变化时重建组件：自定义 RouteReuseStrategy 返回不复用，或给路由出口加 key，让不同 key 对应不同出口。改动面可能覆盖整块区域，但页面状态天然重置，适合本身无状态的详情页。

还有一种做法是进路由前用解析器预取数据，组件初始化时数据已就绪。代价是首屏等待变长，弱网下更容易被感知到，更适合数据量小、进入即展示的场景。

把这三种做法按交付代价排一下，可以形成一组可核对的常见经验区间：

• 只调整一个页面的取参写法：常见区间 0.5～1 人天。
• 还要兼顾滚动位置还原、返回列表态保留、表单草稿处理：常见区间 1～3 人天。
• 改动全局复用策略：影响面按路由数量扩散，通常要配一轮全站回归，常见区间 2～5 人天。

差别主要来自页面内部状态多少，而不是框架本身。上面的区间按页面形态估算，实际还受团队熟悉度和回归范围影响。

交付现场：一次列表到详情的返工

常见情形是：列表跳到详情，详情页用 snapshot 取 id，首次进入一切正常。之后加了「相关推荐」模块，点推荐仍落在同一条路由，只是 id 不同，页面纹丝不动。测试提缺陷时，开发先怀疑接口缓存，因为刷新一次就对了。当时约束是排期只剩两天，详情页还要保住滚动位置和返回态。做法是把取参改成订阅参数流，在回调里重置局部状态并补一个加载态；代价是返工半天外加一轮回归，同时补上「同路由不同参数」的用例。这类返工在项目复盘里被归为同一个前提缺失：进入详情页时，没把参数会变当成默认情况。

适用与不适用边界

参数会变的页面，按参数流处理更稳。典型情况是列表到详情、同一条路由下切换 id 或 Tab、靠 query 参数切换筛选条件，这些场景里参数变化是常态而不是例外。

• 适合按参数流处理：页面偏无状态、参数切换频繁、希望保留滚动位置或返回态。
• 适合让组件重建：页面内部有大量一次性初始化，比如地图实例、编辑器、复杂表单草稿，重建能顺带清掉脏状态。
• 不必额外处理：参数只在进入前确定、页面内不会二次切换的静态详情，用 snapshot 并不会出错，强行改成订阅只是增加代码噪音。
• 要谨慎的地方：自定义 RouteReuseStrategy 影响的是路由整体行为，只为某一个页面动全局策略，容易把其他页面的返回态和滚动位置一起改坏。

验收口径可以定成三句：同一路由换参数进入，页面数据要更新；从详情返回列表再进，滚动位置与筛选条件符合预期；刷新进入与路由进入两条路径结果一致。这三条过了，再谈动画与性能优化才有意义。具体写法按所用 Angular 版本的官方文档与团队验收清单核对。

常见问题

手动刷新页面就正常，能说明是路由复用吗？

大概率能。刷新会重建组件并重新取参，所以内容恢复；但仍要排除入口 HTML 被浏览器缓存的情况，两者表现相似。

snapshot 和订阅 paramMap 到底差在哪？

snapshot 是进入组件那一刻的取值，之后参数再变不会更新；订阅参数流会在每次参数变化时推送新值，适合参数会变的页面。

只是 query 参数变了，同一条路由也会复用组件吗？

默认策略下会，它同样算同一条路由配置。要改用 queryParamMap 订阅，或让组件在参数变化时重建。

用了 OnPush 会不会让这个问题更明显？

属于两个问题。OnPush 影响的是变更检测是否被触发，路由复用影响的是组件是否重建、取参是否更新，排查时先分开确认。

让组件强制重建有什么代价？

页面内部状态、滚动位置、已加载数据都会被重置，动画和请求也会重来一次。无状态页面影响小，复杂页面要提前想好状态恢复。

遇到这类现象，先把刷新页面作为分流动作，再用路由层、生命周期层、数据源层三段核对定位。参数会变的页面按参数流写，参数固定的页面按快照写，不要为了风格统一去动全局路由策略。Angular 版本之间差异较大，2026 年落地前按官方文档和团队验收清单再核一遍。