问题：一次失败请求，为什么需要反复解释？
前端看到接口失败，后端需要复现信息，协作者又想知道影响范围。只发一张截图往往缺少请求参数，只发响应 JSON 又缺少操作背景。复制、补写、再次追问，成为排查过程中的额外工作。
Network Error Reporter 把这些信息组织成一份面向交接的报告。它在 Chrome DevTools 中提供独立的 Error Report 面板，围绕单条失败请求完成选择、补充和导出。
从请求到交接材料
工具读取 HAR 和新完成的请求，默认聚焦失败的 Fetch/XHR。选择请求后，面板提取有价值的信息，再结合手动填写的影响范围、错误频率和复现步骤生成报告。
扩展维护自己的请求列表，用户在扩展面板中选择需要生成报告的请求。Chrome 扩展接口无法直接获取原生 Network 面板当前选中的请求。
报告里应该有什么？
一份可以交接的报告，需要同时回答技术问题和场景问题：请求发到了哪里、返回了什么、用户做了什么，以及接收者下一步该如何验证。
| 信息层 | 典型内容 | 作用 |
|---|---|---|
| 环境与请求 | 页面地址、请求 URL、方法、状态码、耗时 | 定位发生了什么 |
| 请求与响应 | 有价值的头部、参数、负载和响应摘要 | 提供排查证据 |
| 业务上下文 | 影响范围、频率、复现步骤、预期与实际结果 | 说明为何值得关注 |
| 分享检查 | 潜在敏感字段提示 | 提醒分享者检查内容 |
一个匿名示例
假设列表页加载失败，面板选中 GET https://example.com/api/items，响应状态为 503 Service Unavailable。技术字段能说明请求失败，但不能替用户判断业务影响。
补充“打开列表页后点击刷新，预期显示条目，实际出现加载失败”以后，接收者才有可执行的起点。页面首图使用这一类匿名请求展示实际报告界面，不含真实业务流量。
实现取舍：报告比原始数据更接近交接目标
请求归一化与报告生成集中在 panel/report.js，面板交互与预览在 panel/main.js。职责分离让“收集到的数据”和“怎么呈现给人”能够分别处理。
报告会提炼请求和响应中的信息。用户可以选择包含哪些字段，让接收者集中查看排查所需的内容。
分享前的敏感字段检测是提示机制，不是自动脱敏承诺。报告仍需要人工确认，尤其是包含认证头、Cookie、业务参数或响应正文时。
导出与当前边界
- Markdown 适合粘贴到 Issue、工单或协作消息中，保留结构化文本。
- 图片适合快速浏览和转发；导出会优先尝试复制到剪贴板，失败时回退为下载 PNG。
- 当前聚焦单请求，不做多请求聚合分析、原生 Network 截图采集或 HAR 导出。
- 需要 cURL 时，使用 Chrome 原生的 Copy as cURL。
安装可通过开发者模式加载解压后的扩展目录。完整流程和当前功能范围见 项目 README。