Angular 12应用内存占用高、空闲CPU异常触发sigill崩溃咨询

变更检测异常排查（空闲CPU高的最常见诱因） #

• 先量化变更检测触发频率：开启Angular调试工具，在应用启动后于浏览器控制台执行ng.profiler.timeChangeDetection()，如果空闲状态下每秒变更检测触发次数大于1，说明存在异常触发循环。
  • 全量排查模板绑定：禁止在模板插值、*ngFor等结构指令里绑定会返回新引用的方法调用，类似*ngFor="let item of getFilterList()"、{{ calculateValue(item) }}这类写法，哪怕你已经替换了日期转换方法，其他同类方法会在每次变更检测时重新执行，返回新引用触发全量子组件重绘，形成检测循环。
  • 排查手动触发检测的逻辑：全局搜索detectChanges()、markForCheck()、tick()调用，确认这类逻辑没有放在未清理的定时器、requestAnimationFrame循环、未取消订阅的RxJS数据流中，组件销毁时必须中断所有循环、取消订阅。
  • 检查自定义Pipe配置：确认你替换日期方法用的Pipe没有设置pure: false，非纯Pipe会在每次变更检测时重新执行计算，哪怕输入值没有变化，性能和直接在模板写方法调用没有区别。长列表场景下的日期格式化建议直接在数据拉取后提前格式化为字符串，不要放在模板层处理，内置DatePipe底层依赖Intl API，万级以上数据渲染时性能开销极高。

内存泄漏排查 #

• 用Chrome DevTools Memory面板定位泄漏点：页面加载完成空闲1分钟拍第一次堆快照，手动触发GC后拍第二次，再空闲5分钟触发GC拍第三次，对比三次快照中分离DOM节点、闭包引用对象的内存占比，如果数值持续上涨不回落，重点排查三类问题：
  • RxJS订阅未清理：所有自定义订阅、路由事件订阅、全局Service的Subject订阅、WebSocket推送订阅都必须在组件ngOnDestroy生命周期中取消，推荐用takeUntil(this.destroy$)操作符统一处理，避免闭包持有组件引用无法回收。
  • 全局事件未解绑：手动绑定的scroll、resize、键盘事件、第三方SDK的事件回调，必须在组件销毁时调用removeEventListener解绑。
  • 第三方组件未销毁：图表、富文本、地图这类带复杂DOM和内部定时器的组件，初始化后必须调用对应实例的销毁方法，否则会出现大量分离DOM节点无法回收，内存持续上涨直到进程崩溃。

SIGILL崩溃专项排查 #

• 排查编译目标配置：检查angular.json中构建配置的target参数，如果设置为es2020以上，在低版本浏览器、老旧CPU设备上运行时，可能因为CPU不支持新指令集触发SIGILL错误，可先降级到es2017测试崩溃是否复现。
• 排查WASM依赖：如果项目引入了带原生WASM模块的依赖（比如部分加密库、图像处理库、WebAssembly版的运行时），WASM模块内存越界、编译目标不匹配也会触发SIGILL，可在DevTools WebAssembly面板开启调试，捕获崩溃前的调用栈定位问题。
• 快速定位空闲高CPU根因：打开DevTools Performance面板，录制30秒空闲状态的运行数据，直接查看主线程占比最高的长任务调用栈，可直接定位到具体代码行，不需要靠猜测排查。

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