做桌面客户端的早晚会碰上这个需求要把应用里内嵌页面发出的接口请求连响应体一起抓下来做调试面板、做数据留痕、做接口回放或者给测试同学做 Mock。我最初也是最自然的想法——用 Electron 的webRequest监听一下不就完了结果onCompleted打印出来一看只有 URL、状态码、响应头response的 body 影子都没有。翻文档才发现这不是用法错了而是这个 API 从设计上就没打算把响应体交给你。后来陆陆续续把debugger协议、preload 注入、自定义协议几条路都走了一遍各有各的适用面也各有各的坑。这篇就把 Electron 拦截请求并获取 response 的几条主流路线完整拆开讲每条路能拿到什么粒度、参数该怎么算、什么时候会翻车都按我实际踩过的顺序写方便你直接对号入座。1. 先分清谁在拦谁Electron 里能碰到 response 的四个位置1.1 一条请求在 Electron 里走过的三段路Electron 的网络栈其实是分层的理解这个分层比记 API 重要得多。最底下是 Chromium 的网络服务真正的 socket 读写、TLS、缓存、HTTP/2 复用都在这一层往上一层是session它持有 cookie、缓存目录、协议处理器也是webRequest挂载的地方再往上才是渲染进程里的window.fetch、XMLHttpRequest、img、script这些发起方。请求从上往下穿过三层响应从下往上回流你能在每一层的不同位置伸一只手进去。问题在于越往下层走你能看到的东西越原始也越完整但介入成本越高、和业务的距离越远越往上层走介入越容易、跟业务字段贴合得越好但覆盖范围就越窄——页面里一个new Worker()发的请求、img标签预加载、Service Worker 里发的请求你在业务层根本钩不住。所以选型的第一问不是哪个 API 好用而是我到底要覆盖哪些流量。webRequest挂在session层它是 Chromium 提供的网络拦截钩子能看到请求元信息和头部但拿不到响应体。webContents.debugger走的是 Chrome DevTools Protocol等于在浏览器内核和调试器之间插了一根旁路管能拿到的东西最全包括响应体和 WebSocket 帧。preload 注入落在渲染进程的 JS 环境里本质是改写window.fetch和XMLHttpRequest.prototype属于业务层钩子。自定义协议加protocol.handle则是把手伸到 session 的协议处理环节让你自己在主进程里重新发一遍请求那 body 自然随便拿。1.2 四种拦截位置的对比与选型我按实际项目里的使用频率和适用场景整理了一张表你可以先对号入座再往下看具体实现拦截位置能否拿到响应体覆盖范围实现成本典型用途session.webRequest不能该 session 下全部流量低改请求头、改响应头、拦截/重定向、统计耗时webContents.debugger能单个 webContents 的全部流量中抓接口返回、录制回放、性能分析preload 注入 hook能仅 JS 发起的页面主世界里的 fetch/XHR中业务字段级埋点、Mock、错误上报protocol.handle 重定向能被重定向到自定义协议的请求高需要完整控制请求链路的场景这张表里最容易被低估的是第一行的不能两个字。我见过太多人在onCompleted里反复找 body 字段最后怀疑是版本问题。实际是设计如此webRequest的定位是策略钩子而不是抓包工具它能让你决定一个请求要不要发、头部长什么样但不负责把响应内容搬给你因为响应体可能是一个 2GB 的安装包框架不可能默认帮你缓存在内存里。提示如果只是想改个鉴权头、加个 trace id、或者把某个域名下的请求直接取消掉webRequest是成本最低的选择别为了拿 body 就上debugger。选型一定要按需求来不要一刀切。后面四章我按从简到繁的顺序讲但实际项目里经常是组合使用用webRequest做粗粒度过滤和重定向用debugger抓重点接口的 body用 preload 做业务级埋点。2. webRequest 能拿到什么、拿不到什么附 headers 改写实操2.1 五个回调各自的信息粒度session.webRequest下有五个可订阅的事件它们在请求生命周期里的位置不同能拿到的字段也不同。搞清楚这个顺序比背文档有用。onBeforeRequest是最早的钩子请求还没发出去。这时候你能拿到url、method、resourceType、uploadData请求体仅 POST/PUT 等有 body 的请求有以及webContentsId。这个阶段可以做两件事cancel: true直接把请求掐掉或者redirectURL把它改道到另一个地址。注意uploadData是一个数组元素可能是bytesBuffer、file临时文件路径或blobUUID大文件上传时 Chromium 会把它落盘你拿到的只是一个路径引用。onBeforeSendHeaders在请求头组装完成、即将上网络之前触发。这个阶段可以改请求头也能读到最终生效的头部包括 Chromium 自己加的User-Agent、Accept-Encoding之类。做接口签名、加自定义鉴权头的场景基本都挂在这里。onHeadersReceived是响应头到达、响应体还没开始下载的时刻。这是webRequest里信息量最大的一个钩子你能拿到statusCode、statusLine、responseHeaders还能通过 callback 回传修改后的响应头——比如加 CORS 头、改Content-Type、注入Set-Cookie。这一层也是拿不到 body 的因为 body 还没开始传。onResponseStarted和onCompleted只是通知性质前者表示第一个字节到达后者表示整个响应结束。这两个回调里能看到的字段和onHeadersReceived差不多onCompleted多一个fromCache标志能判断这个响应是不是直接从磁盘或内存缓存里拿的——这个字段在做耗时统计时非常关键不然你会把缓存命中的 1ms 当成网络优秀的表现。onErrorOccurred处理失败场景error字段是 Chromium 的错误码字符串比如net::ERR_ABORTED、net::ERR_CONNECTION_RESET。切网、服务端主动断开、被cancel掉的请求都会走到这里。2.2 一份可直接用的 headers 抓取与改写模板下面这段是我项目里抽出来的最小可用版本主进程里注册能同时完成按资源类型过滤打印耗时注入自定义响应头三件事const { session } require(electron) function setupWebRequest (ses) { const filter { urls: [*://*/api/*, *://*/v2/*] } const startAt new Map() ses.webRequest.onBeforeRequest(filter, (details, callback) { startAt.set(details.id, Date.now()) // 只放行 xhr / fetch其余资源类型直接跳过 if (details.resourceType ! xhr) return callback({}) callback({}) }) ses.webRequest.onHeadersReceived(filter, (details, callback) { const headers details.responseHeaders || {} // 注意key 必须小写否则部分版本不生效 headers[x-debug-trace] [String(details.id)] callback({ responseHeaders: headers }) }) ses.webRequest.onCompleted(filter, (details) { const cost Date.now() - (startAt.get(details.id) || Date.now()) startAt.delete(details.id) console.log( [net] ${details.method} ${details.url} - ${details.statusCode} ${cost}ms cache${details.fromCache} ) }) ses.webRequest.onErrorOccurred(filter, (details) { startAt.delete(details.id) console.warn([net:err] ${details.url} ${details.error}) }) } module.exports { setupWebRequest }几个细节值得单独说。filter.urls的匹配模式是 Chromium 的 URLPattern 语法*://*/api/*里的*在 scheme 位置会同时匹配 http 和 https在 host 位置匹配任意主机。如果你的接口分散在多个前缀下宁可多写几条 pattern也不要用*://*/*全量挂——全量挂意味着每一个图片、字体、脚本请求都要走一次你的 JS 回调页面加载时的 IPC 开销会明显上来。responseHeaders的结构是{ [name: string]: string[] }值是数组因为 HTTP 允许同名头重复出现比如多个Set-Cookie。改的时候别直接赋字符串headers[x-foo] bar在某些版本上会让 Chromium 解析异常稳妥写法是包成数组[bar]。2.3 webRequest 层的三个硬限制第一个限制是响应体不可得前面已经说过。第二个限制更容易被忽略session.webRequest上的同名事件如果被注册多次实际生效的是最后一次注册的监听器。这一点在模块化项目里特别坑——两个功能模块都往onBeforeSendHeaders上挂监听后加载的那个会把前面的顶掉表现为某个功能时好时坏。我的做法是在主进程里维护一个单例的事件注册中心所有模块把自己的处理函数注册到这个中心中心再统一挂一次原生监听内部用数组依次调用。第三个限制跟重定向有关。在onBeforeRequest里返回redirectURL会发起一个全新的请求新请求会再次进入onBeforeRequest的过滤逻辑。如果重定向的目标 URL 刚好又命中你的 filter而你的判断条件写得不够收敛就会形成一个自我重定向的循环表现为页面一直转圈、CPU 飙升。防御办法很简单在重定向之前检查目标是否和原 URL 相同或者给重定向后的 URL 打一个 query 标记命中标记就直接放行。注意onHeadersReceived里改响应头改不了Content-Length。如果你试图往响应里塞额外内容而不更新长度Chromium 会按原始长度截断表现为响应体被吃掉一截。这个属于典型的看起来改了其实没生效。3. 用 debugger 协议抓完整 response body3.1 为什么 CDP 能拿到别人拿不到的东西Chrome DevTools Protocol 是浏览器内核对外暴露的调试接口DevTools 面板本身就是一个 CDP 客户端。你在 Network 面板里点开一个请求能看到完整响应体说明内核本来就有这条数据通路只是默认不给外部用。Electron 通过webContents.debugger.attach()把这个通路打开了等于给你的主进程发了一个 DevTools 的席位。所以 CDP 方案的能力上限基本等同于 DevTools响应体、请求体、WebSocket 帧、EventSource 消息、缓存命中情况、重定向链路全都能拿。反过来说它的局限也来自这个身份——一个 webContents 同时只能有一个调试器客户端。开发阶段你习惯性地打开 DevTools 看日志再让代码去attach就会直接抛Another debugger is already attached to the target。这个问题我在头两天遇到了不下十次后来养成习惯在 attach 前面先判断一次。另一个必须提前想清楚的问题是CDP 拿到的是该 webContents 视角的流量。iframe里的请求会带上frameId可以区分但由 Service Worker 在后台发出的请求、以及某些由浏览器进程直接发起的导航请求能否捕获取决于具体版本和启动参数。做流量审计类需求时这一点要提前验证不能想当然。3.2 attach 时机与 Network.enable 参数推演attach的时机非常重要晚一步就会漏掉首屏请求。正确做法是在BrowserWindow创建之后、loadURL之前立刻 attachconst { BrowserWindow } require(electron) function createWindow () { const win new BrowserWindow({ width: 1280, height: 800, webPreferences: { contextIsolation: true, preload: require.resolve(./preload.js) } }) const dbg win.webContents.debugger if (!dbg.isAttached()) { dbg.attach(1.3) } dbg.sendCommand(Network.enable, { maxTotalBufferSize: 200 * 1024 * 1024, maxResourceBufferSize: 20 * 1024 * 1024, maxPostDataSize: 64 * 1024 }) win.loadURL(https://app.internal.local/index.html) return win }三个参数的含义和取值逻辑得说清楚因为它们直接决定能不能拿到 body。maxTotalBufferSize是整个调试会话的响应体缓存总上限单位字节。Chromium 内部维护一个 LRU 队列总量超了就把最早的资源腾出去被腾掉的资源再调getResponseBody就会直接报No resource with given identifier found。默认值量级在 100MB 左右对普通接口完全够用但如果你的应用里有大文件上传下载、有视频流预览很快就会被撑爆。maxResourceBufferSize是单个资源的缓存上限。这个才是真正容易踩空的地方——默认值在几 MB 的量级不同版本有差异别信死数字实测为准意味着一个 10MB 的 JSON 接口返回你调getResponseBody大概率失败。所以只要你的业务里有大响应这个值必须显式调大。具体调多大我的算法是先统计一轮真实业务的响应体分布取 P99 的大小再乘以 2 作为maxResourceBufferSizemaxTotalBufferSize取同时在途的请求数峰值 × maxResourceBufferSize再留一倍余量。比如实测 P99 是 4MB同时在途最多 6 个那maxResourceBufferSize设 8MBmaxTotalBufferSize设 96MB 就够了。别一上来就设成 2GB内存是实打实占的而且 CDP 的 buffer 是在浏览器进程里占的是整个应用的内存。maxPostDataSize控制请求体的缓存只有你需要Network.getRequestPostData时才需要调大默认 64KB 对绝大多数场景足够。3.3 事件时序与 body 抓取的完整实现CDP 里一个请求的完整事件链是Network.requestWillBeSent请求发出→Network.responseReceived响应头到达→Network.dataReceived数据分片到达可能触发多次→Network.loadingFinished或loadingFailed。取 body 的合法时机只有一个loadingFinished之后。在responseReceived里就急着取拿到的要么是半截要么直接抛异常。完整实现需要用一个Map按requestId串联整条链路function startCapture (webContents) { const dbg webContents.debugger const inflight new Map() const results [] dbg.on(message, async (event, method, params) { if (method Network.responseReceived) { const { requestId, response, type } params if (type ! XHR type ! Fetch) return inflight.set(requestId, { url: response.url, status: response.status, mimeType: response.mimeType, fromCache: response.fromDiskCache || response.fromMemoryCache }) return } if (method Network.loadingFailed) { inflight.delete(params.requestId) return } if (method ! Network.loadingFinished) return const meta inflight.get(params.requestId) if (!meta) return inflight.delete(params.requestId) if (meta.fromCache) return // 缓存命中的资源常常取不到 body try { const { body, base64Encoded } await dbg.sendCommand( Network.getResponseBody, { requestId: params.requestId } ) const text base64Encoded ? Buffer.from(body, base64).toString(utf8) : body results.push({ ...meta, body: text.slice(0, 200000) }) webContents.send(net-capture, { ...meta, size: text.length }) } catch (err) { console.warn([cdp] getResponseBody failed, meta.url, err.message) } }) }这段代码里有几个地方是我踩过才加上的。第一inflight.delete要放在取 body 之前否则一旦getResponseBody抛异常这个requestId就永远留在 Map 里跑久了就是一个隐性内存泄漏。第二只处理type XHR || type Fetch不这么过滤的话图片、字体、视频分片会疯狂往 buffer 里塞把真正需要的接口挤出去。第三fromCache的判断一定要有缓存命中的资源在 CDP 里通常没有可取的 body不去过滤就是一堆无意义的报错日志。base64Encoded这个字段要特别注意。文本类响应它一般是false但二进制、图片、或者某些被压缩还原后的内容会是true。如果你不做判断直接把 base64 字符串当正文存下来后面排查数据问题时会被坑得很惨——看起来有内容实际上全是乱码。判断策略我一般按mimeType走匹配json|text|xml|javascript|html|form的当文本处理其余的直接标记为二进制跳过只记录大小和 mime。3.4 缓存上限怎么算才不会踩空关于 buffer 被挤掉的问题我再补一个实战细节。CDP 的缓存是全局 LRU不是一个接口一个坑。所以你精心把maxResourceBufferSize调到 20MB结果页面上同时有 10 个 3MB 的接口在跑总占用 30MB只要你的maxTotalBufferSize设的是 100MB那没问题但如果你设的是 20MB前面几个就会被腾掉getResponseBody全部失败而日志上看起来请求明明成功了。诊断这类问题的办法是在Network.loadingFinished里先打印params.encodedDataLength跟maxResourceBufferSize比一下。如果单个请求的传输长度就超过了单资源上限那必然失败问题一目了然省得去怀疑时序。还有个更隐蔽的情况——流式接口。SSE、长轮询、chunked 大响应这类loadingFinished可能要等连接真正关闭才触发一个挂了十分钟的 SSE 连接你的抓包结果里就是这个请求永远没数据。这种场景别指望loadingFinished直接换思路SSE 用 preload 里包装EventSourceWebSocket 用 CDP 的Network.webSocketFrameReceived事件单独处理。提示webContents.debugger是可以手动detach()的。如果你的抓包功能是用户按 F12 才开启的调试面板记得在关闭面板时调用detach()并清空inflight否则调试器会一直占着席位用户自己开 DevTools 就打不开了。4. 在 preload 里 hook fetch 与 XHR4.1 为什么 hook 必须落在主世界这条路听着最简单——把window.fetch包一层不就完了。但 Electron 的contextIsolation默认是开启的preload 脚本运行在一个隔离的 JS 世界里这个世界的window和页面脚本看到的window不是同一个全局对象。你在 preload 里写window.fetch myFetch改的是隔离世界的引用页面里的业务代码调用的还是原生的fetch。我第一次写的时候就卡在这里日志一条都没有还以为是时序问题。解法是在 preload 里用webFrame.executeJavaScript()把 hook 代码送进主世界执行。这个方法会在页面的主世界里执行一段代码串而且因为 preload 的执行时机早于页面上的任何脚本你能保证 hook 一定在业务代码之前完成。这是这条路能否成立的关键比代码本身重要。// preload.js const { webFrame, ipcRenderer } require(electron) const HOOK_SOURCE (function () { if (window.__netHooked) return window.__netHooked true const report (payload) { try { window.__netReport(JSON.stringify(payload)) } catch (e) {} } const rawFetch window.fetch window.fetch async function (...args) { const started Date.now() const res await rawFetch.apply(this, args) try { const clone res.clone() const ct clone.headers.get(content-type) || let body if (/json|text|xml|javascript|html|form/.test(ct)) { body await clone.text() } else { body [binary: ct ] } report({ via: fetch, url: res.url, status: res.status, cost: Date.now() - started, body: body.length 200000 ? body.slice(0, 200000) : body }) } catch (e) { report({ via: fetch, url: res.url, error: String(e) }) } return res } })() webFrame.executeJavaScript(HOOK_SOURCE)注意res.clone()这一行的必要性。Response.body是一个流只能被读一次页面代码还要读它拿数据你要是直接await res.text()页面那边就拿到一个已经消费过的流会抛body stream already read。所以必须先clone()一份自己读原对象原样返回给业务。这个错误非常典型如果你 hook 完之后页面接口全挂了第一反应就去看是不是忘了 clone。XHR 的 hook 要稍微绕一点因为XMLHttpRequest是事件驱动的得在open的时候记下元信息在load的时候读结果const XHR_HOOK (function () { const proto window.XMLHttpRequest.prototype const rawOpen proto.open const rawSend proto.send proto.open function (method, url, ...rest) { this.__meta { method, url } return rawOpen.call(this, method, url, ...rest) } proto.send function (...args) { this.addEventListener(load, function () { let body try { if (this.responseType || this.responseType text) { body this.responseText } else if (this.responseType json) { body JSON.stringify(this.response) } else { body [ this.responseType ] } } catch (e) { body [unreadable] } window.__netReport(JSON.stringify({ via: xhr, ...this.__meta, status: this.status, body: body.length 200000 ? body.slice(0, 200000) : body })) }) return rawSend.apply(this, args) } })() responseType的判断不能省。当页面用responseType blob或arraybuffer下载文件时直接读responseText会抛InvalidStateError包一层 try/catch 至少能保证 hook 本身不崩不至于因为抓包功能把业务搞挂。4.2 回传主进程的通道设计与体积控制hook 拿到数据之后要回到主进程最省事的是在 preload 里用ipcRenderer.send。但ipcRenderer在隔离世界主世界代码拿不到它所以需要在主世界里挂一个桥接函数由 preload 通过contextBridge或直接赋值的方式暴露出去。上面代码里的window.__netReport就是这么个桥。我一般这样接// preload.js 续 const { contextBridge, ipcRenderer } require(electron) contextBridge.exposeInMainWorld(__netReport, (json) { ipcRenderer.send(net-sniff, json) })这里有个小问题contextBridge.exposeInMainWorld暴露的方法必须在隔离世界里定义而主世界代码是webFrame.executeJavaScript送进去的两边其实是在同一个进程里所以可以直接调用。但要注意参数必须是可序列化的——JSON.stringify之后传字符串是最稳的传对象走contextBridge会有结构克隆的开销。体积控制是这条路最容易翻车的地方。我一开始没设上限结果页面里有个接口一次返回 8MB 的 JSON主进程每个请求都ipcRenderer.send一次完整字符串直接从应用有点卡变成点一下卡三秒。后来加了三个约束单条 body 超过 200KB 只保留前 200KB 并标记truncated连续相同的 URL 在 500ms 内只上报一次去抖主进程侧再做一个总量上限超过就丢最旧的。这三条加上之后才敢在正式包里开这个功能。还有一点preload 注入的 hook 覆盖不到 iframe。页面里如果嵌了别的域名的 iframe那里面的fetch是另一个主世界父页面的 hook 管不着。要全覆盖就得在主进程里遍历webContents.mainFrame.framesInSubtree对每个 frame 单独注入一次。这个逻辑写起来不复杂但容易漏做覆盖率统计类的需求时要专门验证一下。5. 把请求重定向到自定义协议自己取一遍 body5.1 redirectURL 加 protocol.handle 的组合拳前面三条路各有各的盲区webRequest没 bodyCDP 有缓存上限和单调试器限制preload 只能管 JS 发起的请求、管不到标签资源。还有一种比较极端但很管用的思路在onBeforeRequest里把请求重定向到一个自定义协议然后自己实现这个协议在处理器里用主进程的网络能力重新发一遍请求这样 body 就在自己手里了。const { protocol, net, session } require(electron) // 注册自定义协议Electron 25 的写法 protocol.handle(net-mirror, async (request) { const u new URL(request.url) const target decodeURIComponent(u.searchParams.get(target) || ) if (!target) return new Response(missing target, { status: 400 }) const upstream await net.fetch(target, { method: request.method, headers: request.headers }) const buf Buffer.from(await upstream.arrayBuffer()) // 这里 body 已经完全在我们手里了可以分析、落盘、改写 console.log([mirror], target, upstream.status, buf.length) return new Response(buf, { status: upstream.status, headers: upstream.headers }) }) // 在 webRequest 里把目标请求改道 ses.webRequest.onBeforeRequest( { urls: [*://*/api/report/*] }, (details, callback) { const target encodeURIComponent(details.url) callback({ redirectURL: net-mirror://fetch?target${target} }) } )这段代码的威力在于net.fetch走的是 Chromium 的网络栈能正常带 cookie、能走系统证书链、能复用连接池不像自己用 Node 的 http 模块那样要手动处理一堆细节。body 拿到之后你爱怎么分析怎么分析改写之后再用Response返回给渲染进程页面完全无感。5.2 这条路的代价与适用场景代价也很明显我列几个你评估的时候必须考虑的。首先是 origin 变了。页面原本请求的是https://app.internal.local/api/report/x被重定向到net-mirror://fetch?...在渲染进程看来这是一个跨源请求CORS 规则、document.referrer、cookie 的 domain 匹配全都会受影响。如果你的接口依赖 referer 做防盗链校验或者依赖同源 cookie 自动携带这里 cookie 由net.fetch带但也有边界情况就会出问题。其次是错误处理变复杂了。原来网络失败 Chromium 会给出标准的net::ERR_*重定向之后失败发生在你的处理器内部抛什么错、页面看到什么状态全得你自己映射。超时、重试、连接中断都得在handle里手写。所以这条路我一般只用在一个很窄的场景某几个关键接口的响应体必须完整落盘做审计而且这些接口的 URL 是可控可枚举的。用它去覆盖全站流量纯属给自己找麻烦。绝大多数时候CDP 方案加 preload 方案的组合已经够用了。还有一个折中玩法值得一提不用重定向直接用protocol.handle注册一个全新的 scheme让业务侧的请求主动走这个 scheme。比如内部封装一个request()工具函数它的 URL 是app-api://user/profile处理器里拼出真实地址去请求。这样 body 天然可控也不影响其他流量。缺点是需要改业务代码适合从零开始的新模块。6. 常见问题与排查速查表6.1 六个真实翻车现场翻车一getResponseBody报No resource with given identifier found。九成是两种情况一是调用时机早了在loadingFinished之前就取了二是缓存被挤掉了maxResourceBufferSize太小。排查顺序是先看时机日志时机对了再调 buffer 参数。翻车二attach 抛Another debugger is already attached。同一时间只能有一个调试客户端。开发阶段 DevTools 开着就会冲突。解决方式是 attach 前先isAttached()判断并且在应用启动参数里加一个开关调试模式下不自动 attach改成手动触发。翻车三preload 里的 hook 完全不生效日志一条没有。十有八九是没走webFrame.executeJavaScript直接改了隔离世界的window。验证办法很简单在页面控制台里console.log(window.fetch.toString())看是不是function fetch() { [native code] }是原生的就说明 hook 没进主世界。翻车四hook 之后页面接口全挂报body stream already read。忘了clone()。Response的 body 是单次消费流一定要克隆一份自己读。翻车五webRequest的监听有时候生效有时候不生效。多半是同名事件被重复注册覆盖了。把所有监听收敛到一个注册中心全局只挂一次。翻车六改了响应头但页面没反应。检查是不是改在了onBeforeSendHeaders那是请求头以及responseHeaders的 key 有没有大写、值有没有包成数组。还有一个可能是响应走了缓存缓存命中时根本不会触发onHeadersReceived的网络阶段。6.2 排查速查表现象最可能原因验证方式解决方式只拿到 headers 没有 body用了webRequest看用的是哪个 API换 CDP 或 preload hookgetResponseBody失败时序早 / 缓存被挤打印encodedDataLength对比上限等loadingFinished调大 buffer抓到的 body 是乱码base64Encoded未处理打印该字段按 base64 解码再按 mime 转文本hook 无日志隔离世界问题控制台看fetch.toString()用webFrame.executeJavaScript注入页面接口报流已读未clone()看报错栈克隆 Response 后再读attach 失败DevTools 已占用dbg.isAttached()先 detach 或关 DevTools监听时灵时不灵同名事件被覆盖全局搜索注册点收敛到单例注册中心SSE 请求永远没结果等不到loadingFinished观察长连接单独包装EventSource6.3 几条压箱底的经验第一条先把覆盖面想清楚再动手。我做过一个全站接口审计的需求一开始选了 preload hook写完发现页面上有三分之一的请求来自内嵌的第三方页面hook 根本进不去最后返工换成 CDP。判断标准很简单如果流量里包含跨域 iframe、标签资源、Service Worker就必须往 CDP 走如果只关心自家 JS 发的接口preload 足够而且更轻。第二条任何抓 body 的功能都必须有体积上限和脱敏策略。响应体里可能有手机号、有 token、有完整的用户信息这些内容一旦落盘或者上报到远端就是安全事故。我的做法是在采集侧就做白名单只抓配置里列出的 URL 前缀其余一律不落落盘时对常见敏感字段名做正则替换。这个成本很低但能省掉后面一堆麻烦。第三条把抓包功能和业务解耦。别在getResponseBody的回调里做重计算、做同步 IO、做复杂解析CDP 的message事件是串行的你阻塞一下整个调试通道就卡住表现出来是开了抓包页面就变卡。正确做法是回调里只做入队另起一个消费者异步处理队列满了就丢最旧的。最后一个体会这几条路不是互斥的实际项目里最稳的组合是三层——webRequest做粗过滤和头部处理CDP 抓重点接口的完整 bodypreload hook 做业务字段级的埋点和异常上报。三层的requestId对不上没关系用 URL 加时间戳做关联就行。真正上线前我会专门跑一遍全量页面把三条路的数据量各打一份日志确认没有任何一条把内存吃穿才敢开开关。
做桌面客户端的早晚会碰上这个需求要把应用里内嵌页面发出的接口请求连响应体一起抓下来做调试面板、做数据留痕、做接口回放或者给测试同学做 Mock。我最初也是最自然的想法——用 Electron 的webRequest监听一下不就完了结果onCompleted打印出来一看只有 URL、状态码、响应头response的 body 影子都没有。翻文档才发现这不是用法错了而是这个 API 从设计上就没打算把响应体交给你。后来陆陆续续把debugger协议、preload 注入、自定义协议几条路都走了一遍各有各的适用面也各有各的坑。这篇就把 Electron 拦截请求并获取 response 的几条主流路线完整拆开讲每条路能拿到什么粒度、参数该怎么算、什么时候会翻车都按我实际踩过的顺序写方便你直接对号入座。1. 先分清谁在拦谁Electron 里能碰到 response 的四个位置1.1 一条请求在 Electron 里走过的三段路Electron 的网络栈其实是分层的理解这个分层比记 API 重要得多。最底下是 Chromium 的网络服务真正的 socket 读写、TLS、缓存、HTTP/2 复用都在这一层往上一层是session它持有 cookie、缓存目录、协议处理器也是webRequest挂载的地方再往上才是渲染进程里的window.fetch、XMLHttpRequest、img、script这些发起方。请求从上往下穿过三层响应从下往上回流你能在每一层的不同位置伸一只手进去。问题在于越往下层走你能看到的东西越原始也越完整但介入成本越高、和业务的距离越远越往上层走介入越容易、跟业务字段贴合得越好但覆盖范围就越窄——页面里一个new Worker()发的请求、img标签预加载、Service Worker 里发的请求你在业务层根本钩不住。所以选型的第一问不是哪个 API 好用而是我到底要覆盖哪些流量。webRequest挂在session层它是 Chromium 提供的网络拦截钩子能看到请求元信息和头部但拿不到响应体。webContents.debugger走的是 Chrome DevTools Protocol等于在浏览器内核和调试器之间插了一根旁路管能拿到的东西最全包括响应体和 WebSocket 帧。preload 注入落在渲染进程的 JS 环境里本质是改写window.fetch和XMLHttpRequest.prototype属于业务层钩子。自定义协议加protocol.handle则是把手伸到 session 的协议处理环节让你自己在主进程里重新发一遍请求那 body 自然随便拿。1.2 四种拦截位置的对比与选型我按实际项目里的使用频率和适用场景整理了一张表你可以先对号入座再往下看具体实现拦截位置能否拿到响应体覆盖范围实现成本典型用途session.webRequest不能该 session 下全部流量低改请求头、改响应头、拦截/重定向、统计耗时webContents.debugger能单个 webContents 的全部流量中抓接口返回、录制回放、性能分析preload 注入 hook能仅 JS 发起的页面主世界里的 fetch/XHR中业务字段级埋点、Mock、错误上报protocol.handle 重定向能被重定向到自定义协议的请求高需要完整控制请求链路的场景这张表里最容易被低估的是第一行的不能两个字。我见过太多人在onCompleted里反复找 body 字段最后怀疑是版本问题。实际是设计如此webRequest的定位是策略钩子而不是抓包工具它能让你决定一个请求要不要发、头部长什么样但不负责把响应内容搬给你因为响应体可能是一个 2GB 的安装包框架不可能默认帮你缓存在内存里。提示如果只是想改个鉴权头、加个 trace id、或者把某个域名下的请求直接取消掉webRequest是成本最低的选择别为了拿 body 就上debugger。选型一定要按需求来不要一刀切。后面四章我按从简到繁的顺序讲但实际项目里经常是组合使用用webRequest做粗粒度过滤和重定向用debugger抓重点接口的 body用 preload 做业务级埋点。2. webRequest 能拿到什么、拿不到什么附 headers 改写实操2.1 五个回调各自的信息粒度session.webRequest下有五个可订阅的事件它们在请求生命周期里的位置不同能拿到的字段也不同。搞清楚这个顺序比背文档有用。onBeforeRequest是最早的钩子请求还没发出去。这时候你能拿到url、method、resourceType、uploadData请求体仅 POST/PUT 等有 body 的请求有以及webContentsId。这个阶段可以做两件事cancel: true直接把请求掐掉或者redirectURL把它改道到另一个地址。注意uploadData是一个数组元素可能是bytesBuffer、file临时文件路径或blobUUID大文件上传时 Chromium 会把它落盘你拿到的只是一个路径引用。onBeforeSendHeaders在请求头组装完成、即将上网络之前触发。这个阶段可以改请求头也能读到最终生效的头部包括 Chromium 自己加的User-Agent、Accept-Encoding之类。做接口签名、加自定义鉴权头的场景基本都挂在这里。onHeadersReceived是响应头到达、响应体还没开始下载的时刻。这是webRequest里信息量最大的一个钩子你能拿到statusCode、statusLine、responseHeaders还能通过 callback 回传修改后的响应头——比如加 CORS 头、改Content-Type、注入Set-Cookie。这一层也是拿不到 body 的因为 body 还没开始传。onResponseStarted和onCompleted只是通知性质前者表示第一个字节到达后者表示整个响应结束。这两个回调里能看到的字段和onHeadersReceived差不多onCompleted多一个fromCache标志能判断这个响应是不是直接从磁盘或内存缓存里拿的——这个字段在做耗时统计时非常关键不然你会把缓存命中的 1ms 当成网络优秀的表现。onErrorOccurred处理失败场景error字段是 Chromium 的错误码字符串比如net::ERR_ABORTED、net::ERR_CONNECTION_RESET。切网、服务端主动断开、被cancel掉的请求都会走到这里。2.2 一份可直接用的 headers 抓取与改写模板下面这段是我项目里抽出来的最小可用版本主进程里注册能同时完成按资源类型过滤打印耗时注入自定义响应头三件事const { session } require(electron) function setupWebRequest (ses) { const filter { urls: [*://*/api/*, *://*/v2/*] } const startAt new Map() ses.webRequest.onBeforeRequest(filter, (details, callback) { startAt.set(details.id, Date.now()) // 只放行 xhr / fetch其余资源类型直接跳过 if (details.resourceType ! xhr) return callback({}) callback({}) }) ses.webRequest.onHeadersReceived(filter, (details, callback) { const headers details.responseHeaders || {} // 注意key 必须小写否则部分版本不生效 headers[x-debug-trace] [String(details.id)] callback({ responseHeaders: headers }) }) ses.webRequest.onCompleted(filter, (details) { const cost Date.now() - (startAt.get(details.id) || Date.now()) startAt.delete(details.id) console.log( [net] ${details.method} ${details.url} - ${details.statusCode} ${cost}ms cache${details.fromCache} ) }) ses.webRequest.onErrorOccurred(filter, (details) { startAt.delete(details.id) console.warn([net:err] ${details.url} ${details.error}) }) } module.exports { setupWebRequest }几个细节值得单独说。filter.urls的匹配模式是 Chromium 的 URLPattern 语法*://*/api/*里的*在 scheme 位置会同时匹配 http 和 https在 host 位置匹配任意主机。如果你的接口分散在多个前缀下宁可多写几条 pattern也不要用*://*/*全量挂——全量挂意味着每一个图片、字体、脚本请求都要走一次你的 JS 回调页面加载时的 IPC 开销会明显上来。responseHeaders的结构是{ [name: string]: string[] }值是数组因为 HTTP 允许同名头重复出现比如多个Set-Cookie。改的时候别直接赋字符串headers[x-foo] bar在某些版本上会让 Chromium 解析异常稳妥写法是包成数组[bar]。2.3 webRequest 层的三个硬限制第一个限制是响应体不可得前面已经说过。第二个限制更容易被忽略session.webRequest上的同名事件如果被注册多次实际生效的是最后一次注册的监听器。这一点在模块化项目里特别坑——两个功能模块都往onBeforeSendHeaders上挂监听后加载的那个会把前面的顶掉表现为某个功能时好时坏。我的做法是在主进程里维护一个单例的事件注册中心所有模块把自己的处理函数注册到这个中心中心再统一挂一次原生监听内部用数组依次调用。第三个限制跟重定向有关。在onBeforeRequest里返回redirectURL会发起一个全新的请求新请求会再次进入onBeforeRequest的过滤逻辑。如果重定向的目标 URL 刚好又命中你的 filter而你的判断条件写得不够收敛就会形成一个自我重定向的循环表现为页面一直转圈、CPU 飙升。防御办法很简单在重定向之前检查目标是否和原 URL 相同或者给重定向后的 URL 打一个 query 标记命中标记就直接放行。注意onHeadersReceived里改响应头改不了Content-Length。如果你试图往响应里塞额外内容而不更新长度Chromium 会按原始长度截断表现为响应体被吃掉一截。这个属于典型的看起来改了其实没生效。3. 用 debugger 协议抓完整 response body3.1 为什么 CDP 能拿到别人拿不到的东西Chrome DevTools Protocol 是浏览器内核对外暴露的调试接口DevTools 面板本身就是一个 CDP 客户端。你在 Network 面板里点开一个请求能看到完整响应体说明内核本来就有这条数据通路只是默认不给外部用。Electron 通过webContents.debugger.attach()把这个通路打开了等于给你的主进程发了一个 DevTools 的席位。所以 CDP 方案的能力上限基本等同于 DevTools响应体、请求体、WebSocket 帧、EventSource 消息、缓存命中情况、重定向链路全都能拿。反过来说它的局限也来自这个身份——一个 webContents 同时只能有一个调试器客户端。开发阶段你习惯性地打开 DevTools 看日志再让代码去attach就会直接抛Another debugger is already attached to the target。这个问题我在头两天遇到了不下十次后来养成习惯在 attach 前面先判断一次。另一个必须提前想清楚的问题是CDP 拿到的是该 webContents 视角的流量。iframe里的请求会带上frameId可以区分但由 Service Worker 在后台发出的请求、以及某些由浏览器进程直接发起的导航请求能否捕获取决于具体版本和启动参数。做流量审计类需求时这一点要提前验证不能想当然。3.2 attach 时机与 Network.enable 参数推演attach的时机非常重要晚一步就会漏掉首屏请求。正确做法是在BrowserWindow创建之后、loadURL之前立刻 attachconst { BrowserWindow } require(electron) function createWindow () { const win new BrowserWindow({ width: 1280, height: 800, webPreferences: { contextIsolation: true, preload: require.resolve(./preload.js) } }) const dbg win.webContents.debugger if (!dbg.isAttached()) { dbg.attach(1.3) } dbg.sendCommand(Network.enable, { maxTotalBufferSize: 200 * 1024 * 1024, maxResourceBufferSize: 20 * 1024 * 1024, maxPostDataSize: 64 * 1024 }) win.loadURL(https://app.internal.local/index.html) return win }三个参数的含义和取值逻辑得说清楚因为它们直接决定能不能拿到 body。maxTotalBufferSize是整个调试会话的响应体缓存总上限单位字节。Chromium 内部维护一个 LRU 队列总量超了就把最早的资源腾出去被腾掉的资源再调getResponseBody就会直接报No resource with given identifier found。默认值量级在 100MB 左右对普通接口完全够用但如果你的应用里有大文件上传下载、有视频流预览很快就会被撑爆。maxResourceBufferSize是单个资源的缓存上限。这个才是真正容易踩空的地方——默认值在几 MB 的量级不同版本有差异别信死数字实测为准意味着一个 10MB 的 JSON 接口返回你调getResponseBody大概率失败。所以只要你的业务里有大响应这个值必须显式调大。具体调多大我的算法是先统计一轮真实业务的响应体分布取 P99 的大小再乘以 2 作为maxResourceBufferSizemaxTotalBufferSize取同时在途的请求数峰值 × maxResourceBufferSize再留一倍余量。比如实测 P99 是 4MB同时在途最多 6 个那maxResourceBufferSize设 8MBmaxTotalBufferSize设 96MB 就够了。别一上来就设成 2GB内存是实打实占的而且 CDP 的 buffer 是在浏览器进程里占的是整个应用的内存。maxPostDataSize控制请求体的缓存只有你需要Network.getRequestPostData时才需要调大默认 64KB 对绝大多数场景足够。3.3 事件时序与 body 抓取的完整实现CDP 里一个请求的完整事件链是Network.requestWillBeSent请求发出→Network.responseReceived响应头到达→Network.dataReceived数据分片到达可能触发多次→Network.loadingFinished或loadingFailed。取 body 的合法时机只有一个loadingFinished之后。在responseReceived里就急着取拿到的要么是半截要么直接抛异常。完整实现需要用一个Map按requestId串联整条链路function startCapture (webContents) { const dbg webContents.debugger const inflight new Map() const results [] dbg.on(message, async (event, method, params) { if (method Network.responseReceived) { const { requestId, response, type } params if (type ! XHR type ! Fetch) return inflight.set(requestId, { url: response.url, status: response.status, mimeType: response.mimeType, fromCache: response.fromDiskCache || response.fromMemoryCache }) return } if (method Network.loadingFailed) { inflight.delete(params.requestId) return } if (method ! Network.loadingFinished) return const meta inflight.get(params.requestId) if (!meta) return inflight.delete(params.requestId) if (meta.fromCache) return // 缓存命中的资源常常取不到 body try { const { body, base64Encoded } await dbg.sendCommand( Network.getResponseBody, { requestId: params.requestId } ) const text base64Encoded ? Buffer.from(body, base64).toString(utf8) : body results.push({ ...meta, body: text.slice(0, 200000) }) webContents.send(net-capture, { ...meta, size: text.length }) } catch (err) { console.warn([cdp] getResponseBody failed, meta.url, err.message) } }) }这段代码里有几个地方是我踩过才加上的。第一inflight.delete要放在取 body 之前否则一旦getResponseBody抛异常这个requestId就永远留在 Map 里跑久了就是一个隐性内存泄漏。第二只处理type XHR || type Fetch不这么过滤的话图片、字体、视频分片会疯狂往 buffer 里塞把真正需要的接口挤出去。第三fromCache的判断一定要有缓存命中的资源在 CDP 里通常没有可取的 body不去过滤就是一堆无意义的报错日志。base64Encoded这个字段要特别注意。文本类响应它一般是false但二进制、图片、或者某些被压缩还原后的内容会是true。如果你不做判断直接把 base64 字符串当正文存下来后面排查数据问题时会被坑得很惨——看起来有内容实际上全是乱码。判断策略我一般按mimeType走匹配json|text|xml|javascript|html|form的当文本处理其余的直接标记为二进制跳过只记录大小和 mime。3.4 缓存上限怎么算才不会踩空关于 buffer 被挤掉的问题我再补一个实战细节。CDP 的缓存是全局 LRU不是一个接口一个坑。所以你精心把maxResourceBufferSize调到 20MB结果页面上同时有 10 个 3MB 的接口在跑总占用 30MB只要你的maxTotalBufferSize设的是 100MB那没问题但如果你设的是 20MB前面几个就会被腾掉getResponseBody全部失败而日志上看起来请求明明成功了。诊断这类问题的办法是在Network.loadingFinished里先打印params.encodedDataLength跟maxResourceBufferSize比一下。如果单个请求的传输长度就超过了单资源上限那必然失败问题一目了然省得去怀疑时序。还有个更隐蔽的情况——流式接口。SSE、长轮询、chunked 大响应这类loadingFinished可能要等连接真正关闭才触发一个挂了十分钟的 SSE 连接你的抓包结果里就是这个请求永远没数据。这种场景别指望loadingFinished直接换思路SSE 用 preload 里包装EventSourceWebSocket 用 CDP 的Network.webSocketFrameReceived事件单独处理。提示webContents.debugger是可以手动detach()的。如果你的抓包功能是用户按 F12 才开启的调试面板记得在关闭面板时调用detach()并清空inflight否则调试器会一直占着席位用户自己开 DevTools 就打不开了。4. 在 preload 里 hook fetch 与 XHR4.1 为什么 hook 必须落在主世界这条路听着最简单——把window.fetch包一层不就完了。但 Electron 的contextIsolation默认是开启的preload 脚本运行在一个隔离的 JS 世界里这个世界的window和页面脚本看到的window不是同一个全局对象。你在 preload 里写window.fetch myFetch改的是隔离世界的引用页面里的业务代码调用的还是原生的fetch。我第一次写的时候就卡在这里日志一条都没有还以为是时序问题。解法是在 preload 里用webFrame.executeJavaScript()把 hook 代码送进主世界执行。这个方法会在页面的主世界里执行一段代码串而且因为 preload 的执行时机早于页面上的任何脚本你能保证 hook 一定在业务代码之前完成。这是这条路能否成立的关键比代码本身重要。// preload.js const { webFrame, ipcRenderer } require(electron) const HOOK_SOURCE (function () { if (window.__netHooked) return window.__netHooked true const report (payload) { try { window.__netReport(JSON.stringify(payload)) } catch (e) {} } const rawFetch window.fetch window.fetch async function (...args) { const started Date.now() const res await rawFetch.apply(this, args) try { const clone res.clone() const ct clone.headers.get(content-type) || let body if (/json|text|xml|javascript|html|form/.test(ct)) { body await clone.text() } else { body [binary: ct ] } report({ via: fetch, url: res.url, status: res.status, cost: Date.now() - started, body: body.length 200000 ? body.slice(0, 200000) : body }) } catch (e) { report({ via: fetch, url: res.url, error: String(e) }) } return res } })() webFrame.executeJavaScript(HOOK_SOURCE)注意res.clone()这一行的必要性。Response.body是一个流只能被读一次页面代码还要读它拿数据你要是直接await res.text()页面那边就拿到一个已经消费过的流会抛body stream already read。所以必须先clone()一份自己读原对象原样返回给业务。这个错误非常典型如果你 hook 完之后页面接口全挂了第一反应就去看是不是忘了 clone。XHR 的 hook 要稍微绕一点因为XMLHttpRequest是事件驱动的得在open的时候记下元信息在load的时候读结果const XHR_HOOK (function () { const proto window.XMLHttpRequest.prototype const rawOpen proto.open const rawSend proto.send proto.open function (method, url, ...rest) { this.__meta { method, url } return rawOpen.call(this, method, url, ...rest) } proto.send function (...args) { this.addEventListener(load, function () { let body try { if (this.responseType || this.responseType text) { body this.responseText } else if (this.responseType json) { body JSON.stringify(this.response) } else { body [ this.responseType ] } } catch (e) { body [unreadable] } window.__netReport(JSON.stringify({ via: xhr, ...this.__meta, status: this.status, body: body.length 200000 ? body.slice(0, 200000) : body })) }) return rawSend.apply(this, args) } })() responseType的判断不能省。当页面用responseType blob或arraybuffer下载文件时直接读responseText会抛InvalidStateError包一层 try/catch 至少能保证 hook 本身不崩不至于因为抓包功能把业务搞挂。4.2 回传主进程的通道设计与体积控制hook 拿到数据之后要回到主进程最省事的是在 preload 里用ipcRenderer.send。但ipcRenderer在隔离世界主世界代码拿不到它所以需要在主世界里挂一个桥接函数由 preload 通过contextBridge或直接赋值的方式暴露出去。上面代码里的window.__netReport就是这么个桥。我一般这样接// preload.js 续 const { contextBridge, ipcRenderer } require(electron) contextBridge.exposeInMainWorld(__netReport, (json) { ipcRenderer.send(net-sniff, json) })这里有个小问题contextBridge.exposeInMainWorld暴露的方法必须在隔离世界里定义而主世界代码是webFrame.executeJavaScript送进去的两边其实是在同一个进程里所以可以直接调用。但要注意参数必须是可序列化的——JSON.stringify之后传字符串是最稳的传对象走contextBridge会有结构克隆的开销。体积控制是这条路最容易翻车的地方。我一开始没设上限结果页面里有个接口一次返回 8MB 的 JSON主进程每个请求都ipcRenderer.send一次完整字符串直接从应用有点卡变成点一下卡三秒。后来加了三个约束单条 body 超过 200KB 只保留前 200KB 并标记truncated连续相同的 URL 在 500ms 内只上报一次去抖主进程侧再做一个总量上限超过就丢最旧的。这三条加上之后才敢在正式包里开这个功能。还有一点preload 注入的 hook 覆盖不到 iframe。页面里如果嵌了别的域名的 iframe那里面的fetch是另一个主世界父页面的 hook 管不着。要全覆盖就得在主进程里遍历webContents.mainFrame.framesInSubtree对每个 frame 单独注入一次。这个逻辑写起来不复杂但容易漏做覆盖率统计类的需求时要专门验证一下。5. 把请求重定向到自定义协议自己取一遍 body5.1 redirectURL 加 protocol.handle 的组合拳前面三条路各有各的盲区webRequest没 bodyCDP 有缓存上限和单调试器限制preload 只能管 JS 发起的请求、管不到标签资源。还有一种比较极端但很管用的思路在onBeforeRequest里把请求重定向到一个自定义协议然后自己实现这个协议在处理器里用主进程的网络能力重新发一遍请求这样 body 就在自己手里了。const { protocol, net, session } require(electron) // 注册自定义协议Electron 25 的写法 protocol.handle(net-mirror, async (request) { const u new URL(request.url) const target decodeURIComponent(u.searchParams.get(target) || ) if (!target) return new Response(missing target, { status: 400 }) const upstream await net.fetch(target, { method: request.method, headers: request.headers }) const buf Buffer.from(await upstream.arrayBuffer()) // 这里 body 已经完全在我们手里了可以分析、落盘、改写 console.log([mirror], target, upstream.status, buf.length) return new Response(buf, { status: upstream.status, headers: upstream.headers }) }) // 在 webRequest 里把目标请求改道 ses.webRequest.onBeforeRequest( { urls: [*://*/api/report/*] }, (details, callback) { const target encodeURIComponent(details.url) callback({ redirectURL: net-mirror://fetch?target${target} }) } )这段代码的威力在于net.fetch走的是 Chromium 的网络栈能正常带 cookie、能走系统证书链、能复用连接池不像自己用 Node 的 http 模块那样要手动处理一堆细节。body 拿到之后你爱怎么分析怎么分析改写之后再用Response返回给渲染进程页面完全无感。5.2 这条路的代价与适用场景代价也很明显我列几个你评估的时候必须考虑的。首先是 origin 变了。页面原本请求的是https://app.internal.local/api/report/x被重定向到net-mirror://fetch?...在渲染进程看来这是一个跨源请求CORS 规则、document.referrer、cookie 的 domain 匹配全都会受影响。如果你的接口依赖 referer 做防盗链校验或者依赖同源 cookie 自动携带这里 cookie 由net.fetch带但也有边界情况就会出问题。其次是错误处理变复杂了。原来网络失败 Chromium 会给出标准的net::ERR_*重定向之后失败发生在你的处理器内部抛什么错、页面看到什么状态全得你自己映射。超时、重试、连接中断都得在handle里手写。所以这条路我一般只用在一个很窄的场景某几个关键接口的响应体必须完整落盘做审计而且这些接口的 URL 是可控可枚举的。用它去覆盖全站流量纯属给自己找麻烦。绝大多数时候CDP 方案加 preload 方案的组合已经够用了。还有一个折中玩法值得一提不用重定向直接用protocol.handle注册一个全新的 scheme让业务侧的请求主动走这个 scheme。比如内部封装一个request()工具函数它的 URL 是app-api://user/profile处理器里拼出真实地址去请求。这样 body 天然可控也不影响其他流量。缺点是需要改业务代码适合从零开始的新模块。6. 常见问题与排查速查表6.1 六个真实翻车现场翻车一getResponseBody报No resource with given identifier found。九成是两种情况一是调用时机早了在loadingFinished之前就取了二是缓存被挤掉了maxResourceBufferSize太小。排查顺序是先看时机日志时机对了再调 buffer 参数。翻车二attach 抛Another debugger is already attached。同一时间只能有一个调试客户端。开发阶段 DevTools 开着就会冲突。解决方式是 attach 前先isAttached()判断并且在应用启动参数里加一个开关调试模式下不自动 attach改成手动触发。翻车三preload 里的 hook 完全不生效日志一条没有。十有八九是没走webFrame.executeJavaScript直接改了隔离世界的window。验证办法很简单在页面控制台里console.log(window.fetch.toString())看是不是function fetch() { [native code] }是原生的就说明 hook 没进主世界。翻车四hook 之后页面接口全挂报body stream already read。忘了clone()。Response的 body 是单次消费流一定要克隆一份自己读。翻车五webRequest的监听有时候生效有时候不生效。多半是同名事件被重复注册覆盖了。把所有监听收敛到一个注册中心全局只挂一次。翻车六改了响应头但页面没反应。检查是不是改在了onBeforeSendHeaders那是请求头以及responseHeaders的 key 有没有大写、值有没有包成数组。还有一个可能是响应走了缓存缓存命中时根本不会触发onHeadersReceived的网络阶段。6.2 排查速查表现象最可能原因验证方式解决方式只拿到 headers 没有 body用了webRequest看用的是哪个 API换 CDP 或 preload hookgetResponseBody失败时序早 / 缓存被挤打印encodedDataLength对比上限等loadingFinished调大 buffer抓到的 body 是乱码base64Encoded未处理打印该字段按 base64 解码再按 mime 转文本hook 无日志隔离世界问题控制台看fetch.toString()用webFrame.executeJavaScript注入页面接口报流已读未clone()看报错栈克隆 Response 后再读attach 失败DevTools 已占用dbg.isAttached()先 detach 或关 DevTools监听时灵时不灵同名事件被覆盖全局搜索注册点收敛到单例注册中心SSE 请求永远没结果等不到loadingFinished观察长连接单独包装EventSource6.3 几条压箱底的经验第一条先把覆盖面想清楚再动手。我做过一个全站接口审计的需求一开始选了 preload hook写完发现页面上有三分之一的请求来自内嵌的第三方页面hook 根本进不去最后返工换成 CDP。判断标准很简单如果流量里包含跨域 iframe、标签资源、Service Worker就必须往 CDP 走如果只关心自家 JS 发的接口preload 足够而且更轻。第二条任何抓 body 的功能都必须有体积上限和脱敏策略。响应体里可能有手机号、有 token、有完整的用户信息这些内容一旦落盘或者上报到远端就是安全事故。我的做法是在采集侧就做白名单只抓配置里列出的 URL 前缀其余一律不落落盘时对常见敏感字段名做正则替换。这个成本很低但能省掉后面一堆麻烦。第三条把抓包功能和业务解耦。别在getResponseBody的回调里做重计算、做同步 IO、做复杂解析CDP 的message事件是串行的你阻塞一下整个调试通道就卡住表现出来是开了抓包页面就变卡。正确做法是回调里只做入队另起一个消费者异步处理队列满了就丢最旧的。最后一个体会这几条路不是互斥的实际项目里最稳的组合是三层——webRequest做粗过滤和头部处理CDP 抓重点接口的完整 bodypreload hook 做业务字段级的埋点和异常上报。三层的requestId对不上没关系用 URL 加时间戳做关联就行。真正上线前我会专门跑一遍全量页面把三条路的数据量各打一份日志确认没有任何一条把内存吃穿才敢开开关。
