Performance Timeline API 无法捕获内存溢出，因其仅为调试时主动采集的录制机制，不适用于线上环境，且OOM发生时JS引擎已无执行能力；线上需通过performance.memory阈值告警、泄漏指标监控、长任务分析等提前预警。
Performance Timeline API 本身不直接支持线上监控内存溢出，它没有提供捕获“内存溢出（OOM）崩溃”或“堆内存超限终止”的能力。浏览器出于安全与稳定性考虑，不会向 JavaScript 暴露进程级 OOM 事件——一旦 V8 堆真正耗尽（如突破 jsHeapSizeLimit），页面通常会直接卡死、白屏或被浏览器强制终止，此时 JS 已无执行机会。
为什么不能靠 Timeline API 捕获内存溢出
Timeline（现整合进 Performance 面板）是开发者工具中的录制机制，属于**调试时主动采集**功能，依赖 DevTools 后端协议，无法在用户真实环境自动启用。线上环境既无法启动录制，也无法访问 performance.memory 的完整历史曲线数据——该 API 只返回瞬时快照，且仅 Chrome/Edge 支持，Firefox 和 Safari 已明确不实现。
更关键的是：内存溢出发生时，JS 引擎已失去调度能力，不可能触发任何事件监听器或回调函数。所谓“监控溢出”，实质是**提前识别高风险状态，防止走到那一步**。
线上可用的内存压力感知方案
虽然不能捕获“溢出瞬间”，但可通过组合策略，在内存真正崩塌前数秒发出预警：
-
Chrome 环境用 performance.memory 做阈值告警：每 10 秒采样一次，当
usedJSHeapSize / jsHeapSizeLimit > 0.85时上报（注意仅限 Chrome，需加兼容判断）； - 跨浏览器通用的泄漏症状监控：统计 DOM 节点数、事件监听器总数、定时器数量等可枚举指标，若用户完成某操作后这些值持续增长且不回落，说明资源未释放；
-
结合 Long Tasks + 内存快照逻辑推断：若连续出现多个 >200ms 的长任务，且期间
performance.memory?.usedJSHeapSize显著上升，大概率是大对象创建+未释放导致的堆压力激增； - 利用 WeakMap/WeakRef 主动设防：对缓存、tooltip、绑定数据等场景使用弱引用结构，避免强引用阻止 GC，从源头降低溢出概率。
真正能捕获崩溃的替代手段
要拿到“页面因内存耗尽而崩溃”的信号，需借助外部可观测性能力：
- 浏览器崩溃报告（Crash Reporting）：通过 Sentry、Bugsnag 等平台接入 Chromium 的 crashpad 机制（需 native 层配合，前端 JS 无法直接触发）；
- Service Worker + 页面心跳检测：主页面定期向 SW 发送心跳，若 SW 在 5 秒内未收到响应，可标记为疑似卡死/崩溃，并结合 UA、内存快照（如有）上报上下文；
-
Navigation Timing 异常识别：监听
navigationStart到loadEventEnd超过 30 秒，或unload事件长时间未触发，间接推测页面处于不可恢复状态。
不复杂但容易忽略：线上内存问题的关键不是“看到溢出”，而是让系统在 75% 使用率 就开始清理缓存、卸载非活跃模块、暂停非必要动画——把防御线前移到崩溃发生前几秒。
