更高效地提 Bug

很多 Bug 之所以反复扯皮，并不是因为难修，而是因为信息不全

一条报错背后其实藏着不少线索，只是它们大多一闪而过。页面弹出的红框，那句「网络异常」「保存失败」，往往只是包装过的结果，离真正的原因还隔着一层。

好在这些线索没走远，就躺在浏览器的开发者工具里。顺着它们一步步往回找，问题的来龙去脉就能交到开发手上。

报错该去哪看

先打开开发者工具。在出问题的页面上：

• 按 F12
• 或在页面空白处右键，选「检查」
• 或用快捷键：Windows 是 CtrlShiftI，Mac 是 CmdOptionI

顶部有一排标签，接下来只用到两个：Console（控制台）和 Network（网络）。一个报错，要么是前端代码自己抛的，要么是某个接口请求失败的，这两类分别落在这两个面板里。先从 Console 看起。

先看 Console，它通常最先告诉你哪里错了

Console 把页面运行时的报错都收在一起，红色的就是错误。很多问题它一行就说清了，比翻 Network 快；更重要的是，纯前端的崩溃（白屏、组件不渲染、点了按钮没反应）在 Network 里根本没有对应请求，只有 Console 看得到。所以遇到问题，先看这里。

红色报错大致分三类，处理方式不同：

• Uncaught TypeError: Cannot read properties of undefined：前端代码的 Bug，常表现为白屏或某块不显示。点开调用栈能看到出错的文件和行号（如 OrderDetail.jsx:42），这是给开发最直接的线索，务必一起截下来。
• blocked by CORS policy：跨域被拦，多是环境或配置问题，把整段报错发给开发即可。
• GET / POST ... 500 / 404：某个接口失败了。Console 只告诉你哪个接口、什么状态码，要看请求和返回的细节，得转到 Network。

最后这一类，就是接下来的入口。

接口报错，再追到 Network

当 Console 里出现 4xx 或 5xx 的接口报错，说明请求本身出了问题。Network 面板记录每个请求的完整往来：发了什么、回了什么、状态码、耗时。

下面这个 Network 面板可以直接点（数据是模拟的）。create 那条红的就是失败请求，状态码 500。点开任意一条，对比 200 成功、401 登录失效、403 没权限、404 接口不存在，返回的内容各不相同。

状态码这个数字，开发很在意，它直接指向问题的大方向：

一份理想的 Bug 长什么样

把上面截到的东西拼起来，一份让开发「不用再问」的 Bug 大概是这样：

【问题】点击「提交订单」提示保存失败
【报错】Console: order/create 500 (Internal Server Error)
【复现】商品详情页 → 加入购物车 → 结算 → 点提交
【接口】POST /api/order/create  状态码 500
【请求参数】(Payload 截图)  addressId 为空
【返回内容】(Response 截图)  "message": "收货地址不能为空"
【环境】Chrome 126 / 测试环境 / 账号 test001 / 北京时间 14:30

有这些信息，开发基本不用再回来问你，直接就能查。

几个补充手段

写清环境信息

同样的操作，换个环境结果可能完全不同。尽量写清这几项：

• 环境：开发、测试、预发还是生产？
• 账号：用哪个账号触发的？牵涉权限的问题尤其要写。
• 时间：大概几点出的问题，方便开发翻服务端日志。
• 设备和浏览器：Chrome 还是 Safari，电脑还是手机，什么版本。

Copy as cURL

在 Network 里右键那条请求，选 Copy → Copy as cURL，会把整条请求打包成一段文本。开发拿到后能在本地原样重放，定位很快。

录屏加完整复现路径

文字总会漏步骤。录一段十几二十秒的屏，把整条操作路径走一遍，开发就能照着复现。复现不出来的问题，开发很难查。系统自带工具就够：Windows 用 WinG，Mac 用 CmdShift5。

小结

提 Bug 说到底，就是把开发要猜的东西提前替他答好。下次遇到报错，按这个顺序走：