Angular 7应用使用特定Google账号登录时浏览器反复崩溃，如何修复？

第一步：复现并定位性能瓶颈 #

• 开启Chrome DevTools的Performance面板，用出问题的Google账号在非无痕模式下录制开启同步功能的完整操作流程，重点分析执行栈，找长时间占用主线程的循环或递归调用，这类逻辑是CPU占满100%的核心诱因。
• 优先检查和同步功能绑定的数据拉取逻辑：确认是不是每次同步都全量遍历所有历史数据，运行一周后数据量累积到临界值，就会触发超长遍历甚至死循环。
• 你已清理localStorage，但大概率漏了其他持久化存储项，打开DevTools的Application面板，手动删除IndexedDB、Cache API、Service Worker的全部缓存数据，再重试操作看是否能立即复现崩溃，这类存储只有重置浏览器或者手动删除才会清空，无痕模式默认不会持久化存储这些数据。

第二步：针对特定Google账号的排查点 #

• 对比正常账号和异常账号的同步返回数据结构，检查异常账号是否存在超长字段、特殊字符、嵌套层级过深的结构化数据，如果你有手写的序列化、深拷贝逻辑，很可能没有做边界兼容，碰到这类数据就会进入死循环。
• 如果你调用了chrome.storage.sync这类浏览器内置同步接口，要检查该账号下的同步数据是否超出了接口的配额上限，超出后浏览器会持续触发重试逻辑，也会占满CPU。

第三步：隐藏的泄漏逻辑排查 #

你提到已取消所有订阅，注意排查以下容易遗漏的场景：

• rxjs的timer、interval类流式任务，有没有在组件销毁时主动unsubscribe
• 全局事件监听（比如window.resize、跨页面message监听）有没有在销毁时移除
• 父子组件传递的回调有没有形成闭包，长期持有大对象的引用无法被回收
• 用DevTools的Memory面板拍摄堆快照，对比开启同步前后的内存占用，找到持续增长且无法被GC回收的对象。

通用修复方案 #

• 同步逻辑改为增量同步/分页拉取，不要每次全量拉取全量遍历所有历史数据
• 序列化、深拷贝逻辑用成熟的工具库实现，或者增加最大递归深度限制，碰到循环引用直接中断执行
• 所有长耗时、重试类逻辑增加超时中断机制，避免无限重试
• 增加定期清理逻辑，自动删除过期的持久化存储数据，避免IndexedDB等存储的数据量无限制增长

内容的提问来源于stack exchange，提问作者coderPointOfView