4xx 与 5xx — 报错时该看哪里

猜谜游戏是怎么开始的

凡是把网页应用交给 AI 做过的人都熟悉这个场面。屏幕上出现红字，截图丢给 AI，AI 改了代码，还是不行，再截图。几轮之后代码被改了好几处，却没人知道最初的原因是什么。

问题不在能力，而在信息。在不知道哪里坏掉的情况下要求修复，AI 也只能靠猜。反过来，如果把出问题的区段缩小到一处再交给它，同一个 AI 往往一次就能改好。

缩小范围并不需要编程能力。浏览器早已把一半答案显示在屏幕上，而读懂它只需要两条规则：看第一位数字，再顺着边界走一遍。

状态码在哪里看

浏览器本身就自带开发者工具。Windows 按 F12，Mac 按 Command + Option + I，页面旁边或下方就会打开一个面板。Chrome、Edge、Safari 都有，无需安装。Safari 需要先在设置里打开一次“开发”菜单。

面板上的标签只需认识两个。Console 汇集前端代码（JavaScript）留下的消息，Network 则把页面与外部往来的每个请求各列一行。出错时先打开 Network。

保持 Network 标签打开，再点一次出问题的按钮，列表里就会新增一行。标红的那行，或者 Status 列显示 400、500 开头数字的那行，就是元凶。点开它，右侧会显示我们发出的内容（Request）和服务器返回的内容（Response）。

这里重要的不是屏幕上的错误文案，而是这个数字。文案各家不同，数字却是全球通用的约定。

第一位数字决定责任在谁

状态码是三位数，后两位是具体原因，第一位是大类。只看第一位就能确定该看哪一侧。

实战中 4 和 5 的差别最关键。4 表示发送方有问题，要检查自己的页面、输入值和地址；5 表示接收方有问题，再怎么改自己的代码也没用。

只挑常遇到的码来看

不必把所有数字都背下来。真正会碰到的大约十个，只要知道每一个在提示你检查什么就够了。

401 与 403 的差别值得留意。401 的意思是“不知道你是谁”，属于登录问题；403 的意思是“知道你是谁，但你没有权限”，属于权限设置问题。开发中前者叫认证，后者叫授权。

529 不是你的错

使用 Claude Code 或 API 时经常会遇到 529。首位是 5，所以情况出在对方服务器而不是你这边。请求太多，对方扛不住了，通常说成“服务器挂了”。

不知道这一点，就会不停地去改本来没问题的代码，这也是这里最常见的浪费。看到以 5 开头的码，停手，等一会儿再试就是正解。

不过同为 5xx，如果是自己写的后端返回的 500，那就是自己服务器的问题。先分清是自家服务发的 500 还是外部服务发的 5xx，看 Network 标签里那个请求发往哪个地址即可判断。

请求经过的五个区段

用首位定好方向后，接着缩小位置。这需要知道保存一条备忘录时背后发生了什么。网页服务不是一整块，而是下面五个区段串起来的结构。

1）前端。用户看到的画面。以用户为基准位于最前面，所以叫前端。HTML 承载内容，CSS 负责美化，JavaScript 处理点击等动作。由于运行在浏览器内，这里实际上只能用 JavaScript。

2）HTTP 与 API。画面与服务器对话的规格。通过地址（URL）发出请求并接收响应，数据格式多为 JSON。这一整段通信通常被称为 API。

3）后端。看不见的处理方。请求到达后先确认是谁（认证），再看有没有资格（授权），检查值是否正常（校验），然后应用真正的规则。

4）数据库。服务的记忆。把后端处理的结果以表格形式存起来，之后再取出。

5）部署与基础设施。这一切实际运行的地方，也就是走出只在自己电脑上打开的 localhost，放到别人也能访问的位置的过程。

有一个术语容易混。“服务器”并不只指后端程序。从基础设施角度看，它也指运行该程序的那台计算机。后端则是在那台计算机上处理逻辑的程序。

故障发生在区段之间

实务中出问题的位置，多半不在区段内部，而在连接区段的箭头上。变慢了，是某个箭头在延迟；没存上，是某个箭头断了。

所以调试就是按顺序逐个箭头排查。照下面四步走，元凶就会缩小到一个区段。

第一步。重现出问题的动作。保持 Network 标签打开，再点一次那个按钮。

第二步。看请求是否真的发出去了。列表里没有新行，说明在前端就已经被挡住了，这时 Console 标签里往往有 JavaScript 报错。

第三步。发出去了就看状态码。4xx 看发送的值、地址与登录状态；5xx 看后端日志。

第四步。后端也正常的话，确认值是否真的写进了数据库。响应成功却没有数据，问题就在保存逻辑或事务那一侧。

把这个顺序练熟，下次报错时你在发截图之前就已经知道是哪个区段了。

先向 AI 问这个问题

很多人把报错画面贴上去就说“帮我修”。于是 AI 会照着看得见的症状去改代码。若原因在别的区段，这样的修改只会制造新问题。

不如先问位置。下面这段可以直接照抄使用。

这个问题的用处不止于报错。遇到第一次听说的技术名词时用同样的框架去问，就能弄清那项技术处在整体流程的哪个位置。知道了位置，其余的解释才有地方安放。

假设用户请求按 前端 → API → 后端 → 数据库 的顺序流动，
请先判断这个错误出在哪个区段。
把作为判断依据的状态码和日志一并告诉我，
如果还有需要确认的，请说明我该截取什么给你。

假设用户请求按 前端 → API → 后端 → 数据库 的顺序流动，
请说明刚才出现的这项技术影响的是哪个区段。
另外也告诉我，要理解它需要先掌握哪些概念。

遇到不懂的术语就看地图

即使清楚了区段，新术语仍会不断出现。这时 roadmap.sh 很好用。它按角色（前端开发者、后端开发者等）把“按这个顺序学就行”的路线画成一张图。

用法很简单。打开对应的路线图，找出当前卡住的技术处在哪一级。标成紫色的条目是作者推荐的，实际上也就是业界常用的。图是英文的，但可以把它交给 AI 让它讲解。

这样一来，术语就不再是零散堆积，而是变成地图上的坐标。之后无论是搜索还是问 AI，都会快得多。

缺陷不会归零

最后有一个预期需要校正。无论开发者多熟练，缺陷都不会归零。让 AI 来写同样如此，甚至可能造出更多。

所以真实开发中最耗时的并不是第一次写代码的那一刻，而是写完之后：确认、发布、报错、再修，反复循环占了大部分时间。

最终需要的不是没有缺陷的代码，而是出问题时能迅速定位的方法。读首位数字、走一遍边界、先问位置——这三点就能结束大部分猜谜。