用 Chrome DevTools Protocol 调试前端页面的实践笔记

背景

日常排查前端问题时，经常需要复现「只有在特定登录态、特定浏览器环境下才出现」的现象。手工打开 DevTools 一个个试效率很低，用 Chrome DevTools Protocol（CDP）驱动一个独立的浏览器实例会方便很多。这里记录几个实际踩过的点。

1. 用独立 profile 启动，不污染日常浏览器

启动时指定远程调试端口和一个独立的用户数据目录：

chrome.exe --remote-debugging-port=9222 --user-data-dir=<独立目录> <URL>

独立目录的好处是可以随意改设置、清缓存，不会影响日常浏览器；代价是登录态完全隔离，需要重新登录一次。端口就绪后，/json/version 返回浏览器信息，/json/list 列出所有标签页及 targetId，/json/new?<url> 新建标签，/json/activate/<targetId> 把某个标签切到前台。

2. 会话级 Cookie 不落盘，重启就丢

一个常见困惑：明明登录过，重启浏览器后又变回未登录。原因是很多站点使用会话级 Cookie（没有 Expires / Max-Age），只存在内存里，不会写入 Cookies 数据库，直接复制用户数据目录里的 Cookies 文件是无效的。

可行做法是通过 CDP 的 Network.getAllCookies 从运行中的实例读取内存 Cookie，再用 Network.setCookies 注入到另一个实例。注意 sameSite、secure、httpOnly 等属性要一并保留，跨站时按 domain 过滤。

3. 后台标签被节流，停留类逻辑不能只等时间

最隐蔽的一个坑：某页面的「停留 30 秒」逻辑，在后台标签里等了 48 秒也没触发，切到前台后等 40 秒就正常了。原因是 Chromium 对后台标签的定时器做节流，requestAnimationFrame 甚至完全暂停；如果页面用 rAF 或 document.visibilityState 计时，后台时间就不算数。

document.visibilityState  // visible / hidden
document.hidden

需要计时的页面，务必先激活标签再等待。排查时先确认上面这两个值，能省掉很多无效重试。

4. 旧内核的证书与渲染问题

遇到过系统自带的旧版内核打开某站点直接白屏，控制台报 NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED，同时依赖较新语法的单页应用挂载失败。这类问题换用较新的稳定版内核即可，不必在业务代码里找原因。判断依据：先看 document.readyState、挂载根节点的子元素数量、script[src] 数量，能快速区分「应用没挂载」和「接口没数据」。

5. 事件派发要完整

有些组件（尤其封装过的按钮）只监听 pointer 序列，单纯调用 element.click() 不生效。稳妥做法是按顺序派发完整序列：

['pointerdown','mousedown','pointerup','mouseup','click'].forEach(t =>
  el.dispatchEvent(new MouseEvent(t, {
    bubbles: true, cancelable: true, clientX: x, clientY: y, view: window
  }))
);

输入框同理：改完 value 要手动派发 input 和 change，否则框架的双向绑定拿不到新值。用框架提供的原生 value setter 再派发事件，比直接赋值更可靠。

小结

CDP 本身不复杂，真正容易浪费时间的是环境差异：登录态、标签可见性、内核版本、事件模型。先把这四项固定下来，后续定位会顺畅很多。