浏览器数据采集链路诊断

问题从哪来

浏览器扩展、内容脚本或网络拦截器做平台数据采集时，故障往往被当成「某个接口挂了」。实际更常见的是：请求在 Network 里已经是 200/201，后台、账号画像或看板却长期没有数据。新增端点、GraphQL operation、分页或压缩响应后，分类规则和解析器也容易 silently 失效。

把「是否打通」拆成可独立验证的环节，才能避免把传输成功误判为业务完成。

六层模型怎么用

本技能用固定工作流，从下到上（或从捕获到呈现）逐层核对：

1. 捕获层：扩展是否看到目标 URL、方法、状态与响应类型（DevTools Network 或扩展调试）。
2. 分类层：端点规则是否映射到正确的 platform / resource / account（通配符、版本路径、GraphQL、分页）。
3. 传输层：回调是否打到正确环境，认证与幂等键是否有效。
4. 原始层：原始快照是否持久化，字段与组织归属是否完整——不能只看 HTTP 状态。
5. 解析层：解析器版本与字段映射是否覆盖当前响应；「解析 0 条」应视为失败。
6. 呈现层：业务页面用同一账号与时间范围查询，数量、字段与更新时间是否一致。

流程上先固定测试样本（平台、账号、扩展版本、后端环境、一条可唯一识别的数据），每层只修第一个失败层，修复后从该层向下回归。

边界与质量门槛

适用：扩展故障、平台有响应但无数据、验收扩展版本与线上后端组合、补端点/解析器覆盖。

输出结论需指向首个失败层和一条最短修复路径；使用真实页面与 Network 证据，明确版本与环境，同时核对原始快照与标准化结果，不输出 Cookie、Token 或完整响应中的个人敏感数据。