cdp不支持长周期性能采集，需通过轮询+事件监听+状态管理模拟：高频指标用performance.getmetrics定时采样；事件类监听network/page/dom事件；高精度轨迹用tracing分段捕获；须规避websocket断连、oom、页面冻结等陷阱。
CDP 本身不支持“长周期运行”的持续性能采集，它面向的是单次导航、交互或明确起止的追踪任务。所谓长周期（比如页面驻留 10 分钟、用户滚动浏览、后台 Tab 持续运行），必须靠主动轮询 + 事件监听 + 状态管理来模拟，核心是避免内存溢出、时序错乱和指标失真。
明确长周期采集的目标类型
先区分你要的“原始性能指标”属于哪一类，这直接决定用哪个 CDP 域和策略：
-
高频采样类：CPU 使用率、JS 堆内存、DOM 节点数、布局/绘制次数——适合用
Performance.getMetrics定期轮询（如每 2 秒一次），它返回固定 10 个字段，开销低、响应快 -
事件驱动类：资源加载完成、首屏渲染、用户交互（click/input）、滚动触发——监听
Network.responseReceived、Page.lifecycleEvent、DOM.childNodeCountUpdated等事件，按需记录时间戳和上下文 -
高精度轨迹类：FCP、LCP、CLS、帧率、JS 调用栈——必须用
Tracing，但不能全程开启；应分段启用（例如每次滚动开始前 start，滚动结束后 end），否则 trace 文件会迅速达 GB 级别
用 Performance.getMetrics 实现轻量级轮询采集
这是最稳定、最易落地的长周期方式，适用于监控内存泄漏、JS 执行膨胀等缓慢变化问题：
- 在页面加载完成后启用
Performance.enable() - 启动一个定时器（如 Node.js 的
setInterval或 Python 的threading.Timer），间隔建议 1–5 秒，太密会干扰主线程 - 每次调用
Performance.getMetrics，提取Timestamp、JSHeapUsedSize、DomSize、LayoutCount等字段，连同当前 Unix 时间戳一起写入本地文件或发往监控服务 - 注意：该方法无法获取 Web Vitals（如 LCP 元素 ID），它只反映瞬时状态，不带事件上下文
用 Tracing 分段捕获关键交互片段
真正需要帧级精度时，不要试图“一直开着 tracing”，而应聚焦用户行为节点：
- 监听
Page.lifecycleEvent中state === 'interactive'或'complete'，作为首屏后稳定期起点 - 监听
Input.dispatchTouchEvent或DOM.scroll（需配合DOM.enable()）识别用户滚动/点击动作 - 检测到动作后立即
Tracing.start（指定categories: ["devtools.timeline", "loading", "paint", "v8"]），并在动作结束（如Page.lifecycleEvent再次触发或自定义空闲判定）后调用Tracing.end - 每个
Tracing.dataCollected流按 session 或 timestamp 单独保存为 JSON 文件，后续再用工具（如traceviewer或自定义解析器）提取 FCP/LCP/CLS
规避常见陷阱
长周期采集失败，往往不是代码写错，而是忽略了运行时约束：
- WebSocket 连接可能超时断开——必须实现重连逻辑，并在重连后重新
enable所有已订阅的域 - trace events 数据量极大，
transferMode: 'ReturnAsStream'是必须项，否则容易 OOM；收到流后应边收边解析，而非全量缓存 - 页面可能被浏览器自动冻结（尤其是后台 Tab），
Page.lifecycleEvent的state: 'frozen'需捕获并暂停采集，恢复时重新同步状态 - 不要依赖
performance.timing或getEntries()的全局快照——它们只反映页面初始加载阶段，对长周期无意义
