Chrome DevTools 页面、接口与浏览器状态取证工具手册
登录成功之后，第一条业务请求为什么还是 401
测试人员看到的是一个很短的失败现场：登录页已经跳到工作台，用户名也出现在右上角，但列表接口返回 401；刷新后偶尔恢复，换无痕窗口又稳定失败。前端说登录响应是 200，后端说服务端没有收到有效会话，网关日志里还混着来自多次重试的不同 trace id。
这时只看页面提示或复制一条接口 URL 都不够。浏览器实际经历的是一条有状态链路：导航和重定向写入 Cookie，页面脚本从存储读取状态，Service Worker 可能接管请求，网络栈执行缓存、代理、TLS、CORS 和 Cookie 规则，渲染进程再把结果交给 JavaScript。Chrome DevTools 的价值不是“看到报错”，而是把这条链上的中间状态按同一次复现固定下来。
先不要清空所有缓存，也不要立即把请求复制到聊天工具里。前者会破坏故障状态，后者可能泄露会话。正确起点是准备测试账号、可控测试数据和服务端日志查询权限，并记录 Chrome 显示在 chrome://version 的版本、命令行与 profile 路径。Chrome DevTools 随桌面版 Chrome 内置，不需要单独安装；浏览器的发布通道和升级节奏也就是 DevTools 的版本基线。
打开工具时先保住完整请求链
Windows 和 Linux 使用 F12 或 Ctrl + Shift + I，macOS 使用 Command + Option + I，也可以在页面上右键选择 Inspect。如果只想直接看 Console，可用 Ctrl + Shift + J 或 macOS 的 Command + Option + J。这些入口和面板能力以 Chrome DevTools 官方入口 为准。
若快捷键、菜单和右键入口同时不可用，先在 chrome://policy 检查实际生效的 DeveloperToolsAvailability，不要先重装浏览器或修改本地注册表。受管 Chrome 默认允许调试普通页面，但禁止调试由企业策略强制安装的扩展；管理员还可以用 DevTools URL allowlist 和 blocklist 控制可检查的页面。URL 规则会检查页面中的 frame：仅配置 allowlist 时，任一 frame 不匹配都可能使整页无法打开 DevTools；blocklist 命中的 frame 也可能阻断整页，而同时命中时 allowlist 优先。需要例外时应由策略 owner 为测试站点和测试设备发放有期限的最小权限，并在 chrome://policy 验证有效值。策略语义和优先级见 Chrome 企业 DevTools 策略。
打开 Network 后先确认左上角录制按钮为红色，再按故障选择两个设置：
Preserve log 保留重定向和跨页面导航前的请求。登录问题若不开它，跳转前的 302、Set-Cookie 和预检可能在新页面加载时消失。Disable cache 只在 DevTools 打开期间停用浏览器 HTTP 缓存。它用于做缓存正反对照，不等于绕过 Service Worker，也不应长期保持开启。
Network 一行请求不是“接口结果”这么简单。排查时按下面的因果顺序读字段：
| 字段或页签 | 它回答的问题 | 设置或状态改变后的影响 |
|---|---|---|
Status | HTTP、缓存、重定向还是浏览器侧失败 | 304、from disk cache 与 401 代表完全不同的责任点 |
Initiator | 导航、脚本、预加载还是 Service Worker 发起 | 可回到调用栈，避免只盯最终 URL |
Headers | 方法、Origin、Cookie、Authorization、缓存和 CORS 条件是什么 | 展示的 provisional headers 可能意味着请求尚未真正发出 |
Payload | 查询参数、表单或 JSON 是否符合约定 | 这里常含密码、令牌和业务数据，不能原样外发 |
Cookies | 哪些 Cookie 被发送、阻止或写入 | Domain、Path、Secure、SameSite 会决定是否随请求发送 |
Response / Preview | 服务端实际返回什么 | 前端 toast 可能隐藏了网关错误体和 trace id |
Timing | 排队、DNS、连接、TLS、等待首字节、下载各耗时多少 | 节流会改变该结果，比较时必须记录是否启用 throttling |
Size | 线传输量与解压后资源量 | 内存缓存、磁盘缓存和压缩会让两者不同 |
Network reference 记录了过滤器、请求阻断、Copy as cURL、HAR 导入导出等入口。团队升级 Chrome 后若按钮位置或导出选项变化，应从这里复核，而不是依赖旧截图。
用一次正反实验把 401 定到具体环节
在可控测试环境中完成同一次登录，保持 Preserve log，然后按时间顺序找到：登录提交、重定向、会话确认和第一条业务 API。不要先按 Fetch/XHR 过滤，因为文档导航和重定向也可能参与写 Cookie。
正向实验保留正常账号和正常站点数据：
清除 Network 记录，开始录制。从登录页完成一次登录，不手工刷新。在登录响应和重定向响应的 Headers 中检查 Set-Cookie。
在后续业务请求的 Cookies 或 Request Headers 中确认对应 Cookie 是否被发送。在 Response 中记录脱敏后的错误码与 trace id，在 Timing 中确认请求确实到达服务器并收到响应。
预期证据不是笼统的“登录成功”，而是同一个会话标识经历“响应写入 -> Application 可见 -> 请求发送 -> 服务端 trace 对齐”。若这四步成立但仍返回 401，根因更接近会话过期、网关鉴权或后端权限；若 Set-Cookie 已出现但 Application 中没有该 Cookie，重点检查属性和浏览器阻止原因；若 Cookie 已存储却未随请求发送，重点检查目标域、路径、Secure、SameSite 和跨站请求条件。
反向实验只改变一个变量。最有解释力的做法是在测试环境删除目标会话 Cookie，再原样触发业务请求：
在 Application > Storage > Cookies 中删除测试域名下的目标会话 Cookie。不清其他站点数据，不改接口参数。回到页面重试同一个动作。
比较两次请求的 Cookie、状态码、响应错误码和 trace id。
预期故障证据是第二次请求缺少目标 Cookie，服务端返回稳定的未认证响应。若删除 Cookie 后结果没有变化，说明应用可能使用 Authorization、内存状态或另一个 Cookie；若请求根本没进入 Network，则应转向 Console、事件处理和前端分支，而不是继续查后端。
右键请求选择 Copy as cURL 可以验证纯 HTTP 层，但复制结果通常包含 Cookie、令牌和业务参数，必须先在本地编辑副本并替换为 <cookie>、<token>、<user-id>。cURL 成功而页面失败，常提示 CORS、Cookie 策略、Service Worker 或页面状态差异；cURL 失败与浏览器失败一致，才更支持网关、后端或网络链路假设。它不能独自证明浏览器端到端行为。
Console 负责解释“浏览器为什么没有按预期继续”
Network 证明请求发生了什么，Console 解释脚本、平台安全规则和页面上下文为什么这样行动。打开 Console 后保留当前页面上下文，优先处理第一条错误，不要被后续级联异常淹没。
常见证据可以这样分型：
TypeError、未处理 Promise rejection：页面代码在发请求前或处理响应时失败，展开调用栈回到 Sources。CORS 错误：同时回到 Network 检查 OPTIONS、Origin、请求方法、允许头和实际响应。Console 的一句话不是服务端根因。CSP 错误：记录被阻止的资源、指令和来源，避免为了临时通过而放宽整站策略。
mixed content：HTTPS 页面请求了不安全资源，结合 Security 面板确认受影响来源。source map 404：它影响源码定位和证据质量，不一定影响业务运行；不要与业务 API 404 混为一谈。
Console 会执行当前页面权限下的 JavaScript。粘贴陌生脚本、令牌处理代码或所谓“一键修复”相当于把会话交给代码执行。团队排障脚本应进入代码评审过的 Snippet 或仓库脚本，Console 临时命令只做只读查询，并在问题单中记录命令与结果特征。
Application 能区分 HTTP 缓存、站点状态和 Service Worker
“刷新还是旧代码”经常被误判为 CDN 缓存。Application 面板把浏览器持久状态拆成 Cookie、Local Storage、Session Storage、IndexedDB、Cache Storage 和 Service Workers；每一种对象的生命周期和清理后果不同。Application panel 可用于确认这些对象及后台服务状态。
做缓存正反实验时，先保留故障现场：
在 Network 关闭 Disable cache，硬刷新并记录旧资源的 Status、Size、响应头和 Initiator。开启 Disable cache 后再次刷新，比较资源是否仍显示来自 Service Worker。在 Application > Service Workers 检查当前 worker 的 scope、状态和客户端；在 Cache Storage 查找旧资源 URL。
只在测试环境点击当前站点 worker 的 unregister，再刷新一次。
若关闭 HTTP 缓存后旧响应仍由 Service Worker 提供，而 unregister 后请求回到网络并取得新版本，证据指向 worker 更新或缓存版本策略。若 unregister 后仍是旧内容，应继续检查 CDN、反向代理、响应缓存头和构建产物。排障动作不能直接变成生产修复：长期方案要让 worker 激活、缓存命名和旧缓存删除具备可观察的版本迁移。
清理时优先删除实验创建的单个 Cookie、Storage key 或 Cache Storage 条目。Application 的 Clear site data 会同时改变多种状态，只适合确认“全新站点状态是否恢复”，执行前应导出必要证据，执行后重新登录测试账号。不要用清整机浏览数据替代根因定位。
Security 面板把 TLS 与页面安全状态放回同一条链
证书错误、mixed content 和不安全来源需要结合 Security 面板与 Network。重新加载页面后，Security Overview 会给出主来源的安全状态，并列出存在问题的来源。查看证书时重点核对主机名、有效期、签发链和协议；企业代理做 TLS 检查时，还要记录测试机的代理与受信 CA 状态。
看到红色安全提示时，不要使用忽略证书错误的启动参数作为团队方案。正向对照应是受信测试证书、正确主机名和完整链；反向证据可以是在隔离测试域故意使用不匹配主机名，预期浏览器在建立安全连接前阻断，Network 中不会出现正常业务响应。生产修复属于证书签发、链路配置或代理信任治理，而不是前端绕过。
Performance 从“页面卡”落到主线程事件
Network 的 Timing 只解释网络阶段，页面点击后冻结两秒却没有慢接口时，应录制 Performance。先关闭无关标签页和扩展，在同一机器、同一 Chrome 版本、同一节流设置下只录制一个短交互：Performance panel 会呈现主线程任务、调用栈、渲染、布局、绘制和网络事件。
正向实验录制空闲状态下的一次正常筛选，记下交互起点、主线程任务分布和请求 waterfall。反向实验只把数据量切换到能稳定触发卡顿的测试集，再录制同一动作。预期故障证据可能是一个长任务占满 Main、重复布局或大量脚本求值，而不是“CPU 很高”这句结论。
录制设置会影响证据：CPU throttling 是模拟倍率，不代表某款真实设备；网络节流会改变请求时序；开启截图和 JavaScript samples 会增加 trace 体积。团队比较前必须记录这些设置。长时间后台观测、跨用户趋势和线上告警应交给 RUM/APM；DevTools trace 适合短窗口、可复现交互和源码定位。
HAR 是可交换证据，不是无损录像
Network 的 Export HAR (sanitized) 默认排除 Cookie、Set-Cookie 和 Authorization 头；需要敏感版本时，必须先在 Settings > Preferences > Network 显式允许。顶部 Export 按钮适合保存完整记录；只保存筛选结果时，应在请求表中右键选择 Save all listed as HAR (sanitized)，或选择 Copy all listed as HAR (sanitized) 后将结构化 JSON 保存为 .har 文件。不要把界面上已经过滤误当成顶部按钮一定只导出可见行。Chrome 的 HAR 导出说明 也允许导入 HAR 重新检查请求和 initiator。
“sanitized”不代表可以公开：URL 查询参数、路径、请求体、响应体、文件名、业务标识和自定义鉴权头仍可能存在。可靠流程是：
在测试账号和最小数据集上重新复现。先按域名、类型或状态过滤到必要请求，再用 Save all listed 或 Copy all listed 生成 sanitized HAR；若要保留完整时间线，则直接导出全部记录并在下一步结构化裁剪。用结构化 JSON 工具检查 request.url、queryString、headers、cookies、postData、response.content。
删除无关 entry，对保留字段做不可逆替换，并保留原始字段类型。将脱敏副本重新导入 DevTools，确认关键状态码、Timing、Initiator 和 trace id 仍可解释。原始 HAR 放入受限、短保留期位置；问题关闭后按策略删除。
不要在 HAR 文本上做一次全局字符串替换就宣布安全。编码后的请求体、嵌套 JSON、重定向 URL 和自定义 header 很容易漏掉；脱敏脚本需要单元测试与字段 allowlist，附件还要经过人工复核。
把手工证据接进项目和 CI
问题单不应只写“Chrome 有问题”。一个能被前端、后端和测试共同消费的证据记录至少包含：
浏览器版本与 profile 类型：
页面来源与测试账号角色：
唯一复现步骤：
Network 请求链：method / path / status / initiator / timing
Console 第一条错误与调用栈：
Application 状态：Cookie / Storage / Service Worker / Cache Storage
Security 结论：来源 / 证书链 / mixed content
服务端关联字段：脱敏 trace id
变量设置：Preserve log / Disable cache / throttling
附件：脱敏 HAR / trace / 局部截图本地 DevTools 负责探索，CI 负责重复验证。不要试图在 CI 中“打开面板点击按钮”，而应通过浏览器自动化监听 response、console、pageerror，失败时保存 trace，并对 Chromium 使用 Chrome DevTools Protocol 获取确有必要的底层事件。CI 断言业务语义，例如“登录后 /api/session 为 200 且页面无未处理异常”，而不是断言 DevTools 的界面文本。
下面是项目测试应形成的行为契约，具体 API 写法按仓库已锁定的 Playwright 或其他自动化框架版本实现：
given: 隔离测试账号与新浏览器上下文
when: 完成登录并进入工作台
then: 会话确认接口成功，关键响应带可关联 trace id
and: 没有 pageerror 或目标来源的 error 级 Console 消息
on failure: 保存自动化 trace、脱敏请求摘要和服务端日志引用
finally: 删除测试数据并关闭浏览器上下文CI 不应上传带完整 Cookie、Authorization、请求体的 HAR，也不应把远程调试端口暴露给共享 runner 网络。artifact 保留期、访问角色和单次体积上限必须显式配置；否则每次失败都会把高敏证据和大体积 trace 长期堆在制品存储中。
CDP 如何把前端面板连接到浏览器内部
Chrome DevTools 前端本身是一个客户端，它通过 Chrome DevTools Protocol 与浏览器 target 通信。协议按 domain 组织能力，例如 Network、Runtime、Page、Security、Performance；事件携带 requestId、frame、loader 等关联标识，面板再把它们组装成请求表、调用栈和时间线。
这解释了三个常见误区：
HAR 是面板导出的交换模型，不等于 CDP 全事件流；某些缓存、优先级、连接和运行时上下文会被压缩或省略。Performance trace 是跨进程时间线事件集合，不是一张 CPU 截图；事件时间、线程和调用栈必须一起读。DevTools 看到的页面 target 只是浏览器中的一个可调试对象；Service Worker、iframe、扩展和 WebView 可能是其他 target。
临时远程调试可以这样启动桌面 Chrome，先完全退出正在使用同一 profile 的进程：
受管设备还要先在 chrome://policy 检查 RemoteDebuggingAllowed。该策略与“能否打开内置 DevTools”分开控制；被禁用时，--remote-debugging-port 和 --remote-debugging-pipe 都不能作为绕过入口，而且策略变更需要重启浏览器才生效。Chrome Enterprise 的 RemoteDebuggingAllowed 给出了当前支持平台和策略位置。
chrome.exe --remote-debugging-port=9222 --user-data-dir="$env:TEMP\chrome-devtools-lab"然后只在本机检查发现端点：
Invoke-RestMethod http://127.0.0.1:9222/json/version
Invoke-RestMethod http://127.0.0.1:9222/json/list
Invoke-RestMethod http://127.0.0.1:9222/json/protocol预期结果依次包含浏览器与协议版本、可调试 target 列表，以及这个运行中实例真正支持的 domain、command、event 和类型定义；连接工具应使用返回的 WebSocket debugger URL，并按 /json/protocol 做能力发现，而不是照抄 tip-of-tree 文档或猜测路径。CDP 的 tip-of-tree 能力会变化且不保证向后兼容，稳定 1.3 又只是较小子集，浏览器自动化应锁定浏览器构建和客户端版本，并对可选 domain 做存在性判断。Chrome 136 起，--remote-debugging-port 和 --remote-debugging-pipe 对默认数据目录不再生效，必须配合非默认 --user-data-dir；自动化场景可评估 Chrome for Testing。这个安全变化见 Chrome 远程调试端口说明，协议版本边界见 Chrome DevTools Protocol。
排障完成后关闭该 Chrome 进程，确认端口不再监听，再删除临时目录：
Get-NetTCPConnection -LocalPort 9222 -ErrorAction SilentlyContinue
Remove-Item -LiteralPath "$env:TEMP\chrome-devtools-lab" -Recurse -Force删除前必须确认目录就是本次创建的临时 profile，不能对日常用户目录执行该命令。远程调试端口拥有读取页面、执行脚本和控制 target 的能力；即使只在内网，也应使用主机防火墙、短生命周期进程和受控隧道，不与个人登录 profile、生产账号或密码管理扩展共存。
Chrome、cURL、代理和自动化工具怎么分工
| 需要回答的问题 | 首选工具 | 换工具的信号 |
|---|---|---|
| 页面为什么发出这条请求 | DevTools Network + Initiator + Console | 需要长期自动回归时转浏览器自动化 |
| HTTP 请求脱离页面是否仍失败 | cURL / HTTPie | 涉及 Cookie、CORS、SW、渲染时回到浏览器 |
| 代理前后字节或非浏览器客户端差异 | Charles、Fiddler、mitmproxy、Wireshark | 需要页面脚本上下文时回到 DevTools |
| 一个交互为什么阻塞主线程 | Performance | 需要真实用户长期趋势时转 RUM/APM |
| 多版本、多平台是否回归 | Playwright / WebDriver + CI | 首次未知故障先用 DevTools 探索证据 |
| 程序化读取浏览器底层事件 | CDP 客户端 | 跨浏览器稳定契约优先使用自动化框架抽象 |
DevTools 是桌面 Chrome 的内置能力，没有独立座席价格或单独团队套餐；真实成本来自浏览器版本矩阵、测试设备、CI 分钟、artifact 存储、证据审查和维护自动化脚本。团队如果把所有页面都永久录 trace、所有失败都存完整 HAR，成本和泄露面会同时增长。
长期治理要控制版本、容量和证据寿命
团队基线不应锁死一个永不升级的 Chrome，而应记录支持的发布通道、最低业务兼容版本、CI 浏览器构建号和升级 owner。浏览器升级先在小范围跑登录、支付、上传、下载、Service Worker 更新、证书和性能基线，再扩大覆盖；出现回归时回滚 CI 镜像或浏览器通道，同时保留新旧版本的同条件证据。
容量治理关注的是证据增长而非 DevTools 本身：
HAR 按问题最小化请求集合，默认 sanitized，原始敏感副本短期受控保存。Performance trace 只录稳定复现窗口，设置单文件大小和 CI artifact 保留期。Console 日志按来源和级别过滤，不把用户输入、token 或完整响应写入日志。
远程调试会话设置 owner、用途、端口、开始与结束时间，结束后验证进程和端口均关闭。调试 profile 不登录个人账号，不同步，不安装密码管理器和无关扩展，按任务销毁。
一次排障可以在这些证据齐备时停止：关键请求的发起者、浏览器状态、网络结果和服务端 trace 已能互相解释；正反实验只改变一个变量且结果可重复；临时 profile、调试端口、测试账号和本地证据已经回收。缺少其中任何一环，都不应把“刷新好了”当成修复完成。
交付证据前逐项复核
记录 chrome://version，并说明是否使用独立调试 profile、扩展和节流。Preserve log 捕获了导航、重定向、预检和业务请求的完整顺序。Network、Console、Application、Security 的结论来自同一次复现。
缓存实验区分了 HTTP cache、Service Worker、Cache Storage 与上游缓存。Performance 只录一个可重复交互，并记录 CPU / Network throttling 设置。Copy as cURL、HAR、trace 和截图均使用测试数据并完成二次脱敏复核。
CI 断言业务行为，失败附件有权限、大小和保留期限制。CDP 使用非默认临时 profile，端口未暴露到共享网络。受管设备已核对 DeveloperToolsAvailability 与 RemoteDebuggingAllowed，协议客户端按运行实例的 /json/protocol 发现能力。
排障后关闭浏览器进程、确认端口消失、删除本次临时 profile 和测试数据。