张云雷宝宝做后端开发这几年，我越来越觉得 HTTP 协议是这行最值得花时间吃透的基础功。平时排查线上问题，很多同事第一反应是翻日志、问中间件、重启服务，但真正高效的做法往往是拿起 curl 看一眼状态码，翻一眼响应头，问题基本就能定位一半。我自己也是从“只要能打开网页就行”的阶段走过来的，所以想把 HTTP 协议从头到尾掰开揉碎讲一遍：它到底是什么、一次请求怎么跑完、状态码背后的含义、连接为什么能复用、HTTPS 多出来的那个 S 到底保护了什么，以及那些你在命令行里常见的 HTTP 报错应该怎么查。不管你是刚入行的前端、后端、测试，还是偶尔要跟接口打交道的运维，这篇文章应该都能让你少踩几个坑。
1. HTTP 是什么：从一次网页冲浪说起
1.1 一个看似普通却充满协议的瞬间
你在浏览器里输入一个网址，按下回车，几秒钟后页面就出来了。这个过程中间发生了什么？简单说，你的浏览器向目标服务器发起了一个 HTTP 请求，服务器处理完以后把 HTML、CSS、JavaScript 甚至图片通过 HTTP 响应返回给浏览器，浏览器再把这些资源渲染成你看到的页面。
HTTP 的全称是 HyperText Transfer Protocol，超文本传输协议。它工作在应用层，规定的是“客户端和服务器之间用什么格式对话”。它并不管数据怎么打包、怎么走网络，那些是 TCP/IP 的事。HTTP 关心的是更上层的问题：我请求什么资源、用什么方法请求、服务器返回了什么状态、内容是什么格式。
打个比方，HTTP 就像你去餐厅点餐。菜单是服务器能提供的资源列表，你告诉服务员“我要一份宫保鸡丁，不要花生”这句话就是请求，后厨按你的要求做好菜端上来就是响应。如果某个菜没有了，服务员会告诉你“抱歉这个卖完了”，对应到 HTTP 里就是 404 Not Found；如果后厨出了事故出不了菜，那就是 500 Internal Server Error。
这个类比不严谨，但足够帮你建立第一层直觉：HTTP 是一种有格式、有状态码、有语义的对话协议。
1.2 HTTP 的三条核心约定
理解 HTTP 的关键，在于记住三条约定。
第一条，客户端-服务器模式。HTTP 通信永远是客户端主动发起，服务器被动响应。浏览器是客户端，手机 App 是客户端，命令行里的 curl、wget 是客户端，你用 Python 的 requests 库写爬虫也是客户端。服务器不会无缘无故主动给你推数据，除非你用了 WebSocket 或者其他基于 HTTP 升级的机制。
第二条，无状态。HTTP 本身不记忆你之前的请求。你上一次请求带了什么参数、登录没登录，服务器在默认情况下是不知道的。这就是为什么后来出现了 Cookie、Session、Token 这些东西，它们存在的意义就是在一堆无状态的 HTTP 请求之间，人为地建立“记忆”。很多新手第一次接触登录功能时会被绕晕，其实就是没搞清楚“HTTP 无状态”这个底层前提。
第三条，可扩展。HTTP 的请求头、状态码、方法都不是封闭死板的，设计者预留了大量扩展空间。你可以在请求头里加自定义字段，可以用状态码表达各种业务语义，还可以通过 Content-Type 协商传输 JSON、表单、文件、流式数据。正是这种可扩展性，让 HTTP 从最初传输 HTML 文档的协议，变成了今天几乎所有 Web API 的通用语言。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一次 HTTP 请求的完整解剖
2.1 请求行：你准备对服务器做什么
一次完整的 HTTP 请求，在报文层面长什么样？以 HTTP/1.1 为例，请求报文由三部分组成：请求行、请求头、请求体。
请求行是第一行，格式是：
code复制方法 路径 协议版本
例如：
code复制GET /index.html HTTP/1.1
POST /api/user/login HTTP/1.1
这一行告诉了服务器三件事：你要用什么动作、你要操作哪个资源、你用的是哪个协议版本。路径部分有时候会带上查询参数，比如 /search?keyword=http&page=1，这些参数本质上也是请求信息的一部分，但它们被放在 URL 里，而不是请求体里。
2.2 请求头与请求体：上下文与数据
请求头从第二行开始，一直到空行结束，每一行都是“键: 值”的格式。常用的请求头有这些：
- Host：目标主机名和端口。HTTP/1.1 之后这个字段是必选的，因为一台服务器可以托管多个域名，服务器要靠 Host 区分你访问的是哪个站点。
- User-Agent：客户端的类型和版本。服务器可以据此判断你是浏览器、爬虫还是手机 App，有些反爬手段就是靠识别这个字段。
- Accept：你希望服务器返回什么类型的内容，比如
text/html、application/json。 - Content-Type：请求体的媒体类型。POST JSON 数据时是
application/json，提交表单时是application/x-www-form-urlencoded，上传文件则是multipart/form-data。 - Authorization：认证凭证，常见格式是
Bearer <token>或者Basic <base64字符串>。 - Cookie：浏览器自动带上之前服务器 Set-Cookie 存下来的会话信息。
空行之后就是请求体，主要用在 POST、PUT、PATCH 这类需要携带数据的请求里。GET 请求一般没有请求体，但这只是约定俗成，不是协议强制。
2.3 响应：服务器给出的答案
服务器收到请求后，会返回一个 HTTP 响应报文，结构长这样：
code复制HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Set-Cookie: session_id=abc123; Path=/
<html>...</html>
第一行叫状态行，由协议版本、状态码和状态描述组成。200 OK 是最常见的，表示一切正常。状态行下面是响应头，里面带着 Content-Type、Content-Length、Cache-Control、Set-Cookie 等信息，告诉你返回内容是什么格式、有多长、能不能缓存、要不要种 cookie。
空行之后是响应体，也就是你真正要的数据，可能是 HTML 页面、JSON 字符串、图片二进制流或者文件内容。
我建议所有入行的开发都做一件事：在命令行里跑一次 curl -v https://www.baidu.com，亲眼看看请求行、请求头、响应头是怎么一对一发出去的。刚开始可能觉得乱，但看多了自然就懂，比起任何教程都直观。
3. HTTP 方法与状态码实战速查
3.1 常用方法一次看懂
HTTP 方法定义了“你想对资源做什么”。理论上你可以自定义方法，但实际开发中常用的就那几个。
GET 用来获取资源，应该是幂等的，重复执行不应该改变服务器数据。POST 用来提交数据，可能创建资源也可能触发复杂操作，不要求幂等。PUT 一般用来全量更新资源，它有一个重要特性是幂等，意思是同一个请求执行多少次，结果都一样。PATCH 用于部分更新资源，不需要完整的数据体。DELETE 用来删除资源。
HEAD 和 GET 唯一的区别是服务器只返回响应头不返回响应体，常用于检查资源是否存在、拿 Content-Length 判断文件大小。OPTIONS 用于探测服务器支持哪些方法和跨域规则。在浏览器跨域请求时，如果请求方式比较复杂，浏览器会先发一个 OPTIONS 预检请求问服务器“允不允许我这么干”。
3.2 状态码：把服务器的话翻译成人话
状态码是个三位数，第一位数字代表大类，后两位是细分。很多人觉得状态码难记，其实只看首位就够了：
- 1xx：信息性响应。比较少见，比如 101 表示协议切换，WebSocket 握手时会用到。
- 2xx：成功。200 是标准成功，201 表示创建成功，204 表示成功但没有响应体。
- 3xx：重定向。301 永久重定向，302/307 临时重定向，304 Not Modified 表示资源没变，可以直接用浏览器缓存。
- 4xx：客户端错误。400 请求格式不对，401 未认证，403 禁止访问，404 资源不存在，405 方法不允许，429 请求太频繁被限流。
- 5xx：服务器错误。500 服务器内部出错，502 网关收到上游服务器的无效响应，503 服务暂时不可用，504 网关超时。
3.3 这几个状态码踩坑概率极高
在实际项目里，有几个状态码几乎是每天都能遇到的，值得单独说。
400 Bad Request 是前端最讨厌也最常见的。它表示服务器读不懂你发来的请求，常见原因包括 JSON 格式错误、参数类型不对、必填字段缺失、Content-Type 跟请求体不匹配。曾经我排查过一个接口，客户端怎么调都是 400，最后发现是请求头里带了 Content-Type: application/json，但请求体却是空的。服务器解析不到内容，直接就拒绝了。
401 Unauthorized 表示你没有通过认证，也就是“你是谁我都不知道”。常见的报错形式是 {"code":30014,"message":"token is invalid."}，这类错误排查优先级最高的是看 Authorization 头有没有带对、token 是不是过期了。
502 Bad Gateway 是部署架构里最常见的错误。它意味着中间的反向代理（Nginx、网关）把请求转发给后面的应用服务器时，得到的响应是无效的。用命令 curl http://127.0.0.1:15721/v1/responses 直接访问本机端口，大概率能看到 502，说明是本地端口上的服务挂了没起来，或者返回了无法解析的响应。定位思路很简单：先确认应用进程在不在，再确认端口有没有监听，再看应用日志有没有报错。
4. 连接复用与连接管理：性能提升的关键
4.1 从每次新建连接到 Keep-Alive
早期的 HTTP/1.0 有一个很低效的设计：每次请求都要新建一次 TCP 连接，请求结束后连接就关闭。而一次 TCP 连接从建立到销毁，需要经过三次握手、数据传输、四次挥手，费用相当高。如果一个页面有 50 个资源要加载，浏览器就要反复建连、断开 50 次，网络开销大得离谱。
HTTP/1.1 引入了持久连接，也就是常说的 Keep-Alive 机制。默认情况下，同一个 TCP 连接可以处理多个请求，只要连接没有超时或者被显式关闭。这就是“连接复用”的由来。服务器在响应头上会带 Connection: keep-alive，客户端复用它继续发下一个请求，省掉了重复握手的开销。
我在用 wget 下载资源时体会特别深。命令行为：
bash复制wget http://fishros.com/install -o fishros && . fishros
很多人只是把这一行当成“下载脚本并执行”，实际上 wget 默认会尝试复用连接，如果一个页面里有多个资源，它会在同一个连接里批量下载，比逐个建立连接快得多。这条命令里还有一个特别值得注意的点：&& 代表前一条命令成功后才执行后一条，如果把 . fishros 替换成 bash fishros，效果其实不太一样，前者是在当前 shell 里执行脚本，可以保留脚本里设置的环境变量。
4.2 实际开发中的连接池配置
连接复用、连接池这几个关键词，在后端开发里几乎天天碰到。要说 HTTP 连接管理，最典型的问题就是“明明服务没挂，但请求超时、连接打不出去”。我见过最经典的一次故障：Java 服务用 HttpClient 调外部接口，没有配置连接池的最大连接数，默认值小得可怜，线上流量稍微一大，连接就被占满，新请求只能排队等连接，最后全部超时。
现在的主流 HTTP 客户端，无论是 Java 的 HttpClient、Apache HttpClient，还是 Go 的 net/http，Python 的 requests，底层都支持连接池。核心配置就几个概念：
- 最大连接数：连接池里最多同时保持多少条连接。
- 单路由最大连接数：同一台目标服务器最多分配多少条连接。
- 连接空闲超时：空闲连接超过这个时间就关闭，释放资源。
- 连接获取超时：从连接池里拿不到连接时最多等多久。
正确的姿势是给每个外部依赖单独建连接池，避免所有请求共用一个池子，互相拖累。另一个容易忽略的点：连接的 TTL（最大存活时间）建议设置得比服务端的 keep-alive 超时短一些，否则你从池子里拿到的连接，可能已经被服务器静默关闭了，发请求过去就报连接重置或者 EOF。
还有一个隐蔽的坑是 TCP 层面的 TIME_WAIT。如果你的服务频繁地创建短连接，然后主动关闭，系统就会积累大量处于 TIME_WAIT 状态的连接，导致端口被占满，新连接无法建立。我遇到过一台机器上大量 Cannot assign requested address 报错，netstat 一看全是 TIME_WAIT，解决方案就是调整 tcp_tw_reuse 内核参数，同时优化代码里的连接管理策略，尽量用长连接。
5. HTTP 与 HTTPS：差的不只是一个 S
5.1 明文传输的隐患
HTTP 最大的问题是：整个通信过程是明文传输的。你在网络上发的每一个请求、每一个响应，中间经过的每一台路由器和交换机都能看到内容。如果你的请求里有用户名、密码、手机号、支付信息，这些敏感数据就相当于在大街上裸奔。
我在排查问题时经常看到浏览器控制台报一条警告：某个文件通过 HTTP 加载了，但整个页面本身是 HTTPS 的。比如搜索词里出现过 was loaded over an insecure connection. this file should be served over http，真实场景是浏览器提示“某个脚本/图片/样式是通过不安全的连接加载的，请改用 HTTPS”。现在主流浏览器的安全策略越来越严格，混合内容（HTTPS 页面里夹杂 HTTP 资源）轻则被警告，重则直接被拦截。
5.2 加密握手是怎么工作的
HTTPS 的全称是 HTTP Secure，它的本质是在 HTTP 和 TCP 之间加了一层 TLS/SSL 加密协议。数据在发送前会被加密，接收后再解密，中间人即使截获了报文，看到的也是一堆密文。
TLS 握手的过程大致是这样的：
- 客户端发一个 ClientHello，告诉服务器它支持的 TLS 版本、加密套件列表。
- 服务器回一个 ServerHello，选定加密套件，同时把数字证书发给客户端。
- 客户端验证证书的合法性，确认服务器身份无误。
- 双方通过非对称加密协商出一个对称加密密钥，之后的所有数据都用对称加密传输。
用更通俗的方式理解：非对称加密负责“安全地交换钥匙”，对称加密负责“高效地锁门开门”。之所以两套加密都要用，是因为非对称加密虽然更安全但速度慢，对称加密虽然快但需要先解决“钥匙怎么安全送达”的问题。
证书的作用是让客户端相信“跟我对话的确实是这个域名的拥有者”。证书由 CA（证书颁发机构）签发，浏览器内置了一批可信 CA 的根证书。如果证书过期、域名不匹配或者签发者不被信任，浏览器就会报警。
5.3 从 HTTP 迁到 HTTPS 的注意事项
很多团队以为给网站配了 HTTPS 证书就万事大吉，实际上一堆细节容易踩坑。
首先是证书有效期。Let‘s Encrypt 的证书只有 90 天，如果忘记续期，到期后访问就会出现警告。最好用 certbot 之类的工具部署自动续期任务。
其次是混合内容问题。HTTPS 页面里如果还引用 http:// 开头的图片、脚本、样式，浏览器会拦截部分类型的资源或者降低安全评级。迁移时要全局搜索代码里所有 http:// 的外部资源地址，改成 https:// 或者直接用协议相对地址 //。
再次是 301 重定向。要把所有 HTTP 访问永久重定向到 HTTPS，用 301 而不是 302，因为 302 是临时重定向，搜索引擎会继续保留原 HTTP 页面。配置好后可以用 curl -I http://你的域名 看一眼返回的状态码，应该是 301。
最后还有 HSTS。启用 HSTS 后，浏览器会强制用 HTTPS 访问你的域名，连 301 重定向这一步都省了，从源头上杜绝了降级攻击。
6. 协议生态：HTTP 与网络协议大家庭
6.1 网络分层里的 HTTP
日常开发中你会听到各种协议的名字：TCP/IP、Modbus、MQTT、CAN、SPI、I2C、NMEA、Hart、OCPP、RTMP。这些协议出现的时候，很多人会搞混它们之间的关系，其实关键看分层。
HTTP 位于 TCP/IP 模型的应用层，它依赖 TCP 提供可靠的传输保证。TCP 负责把数据切包、排序、重传，IP 负责寻址和路由。可以说 TCP/IP 是高速公路和物流系统，HTTP 是物流单据上写的收货信息和货物清单。
而 CAN、SPI、I2C 这些更多是物理层/链路层的通信协议，常用在嵌入式设备、传感器、单片机内部的通信场景。它们跟 HTTP 基本不在一个层级，也不存在谁替代谁的问题。一个 STM32 单片机可以用 SPI 跟传感器通信，也可以嵌入一个 lwIP 协议栈之后用 HTTP 对外提供 Web 接口，两者各司其职。
6.2 什么时候选择 MQTT 而不是 HTTP
在物联网场景里，很多人会纠结到底用 HTTP 还是 MQTT。我的观点是：取决于业务场景。
HTTP 是请求-响应模式，适合客户端主动获取数据、RESTful API 这种场景。它简单、通用、调试方便，但有一个明显的短板：服务器不能主动推数据。如果设备要实时接收指令，HTTP 就得靠轮询不断问服务器“有没有新消息”，效率很低，而且费电费流量。
MQTT 是发布-订阅模式，基于 TCP 实现，专为低带宽、高延迟、不稳定的网络环境设计。设备可以维持一条长连接，服务器可以随时往某个主题推消息，所有订阅了这个主题的设备都能收到。在智能家居、车联网、传感器数据上报这些场景里，MQTT 比 HTTP 合适得多。
我在接触充电桩项目时看过 OCPP 1.6 协议，它用的就是 WebSocket 加 JSON，本质上是把 HTTP 升级成双向通信通道。可见行业方案一般不会只认死一种协议，更多是根据需求组合使用，HTTP 足够胜任的场合没必要引入 MQTT 增加复杂度。
6.3 robots.txt：HTTP 上的君子协议
搜索热词里出现了“淘宝网的 robots 协议”，这不只是前端界面的东西，它本质上是一份通过 HTTP 提供访问的文本文件，放在站点根目录下，比如 https://example.com/robots.txt。里面用 User-agent 和 Disallow 指令告诉爬虫哪些路径可以抓、哪些不能抓。
说它是君子协议，是因为它没有任何强制力。恶意的爬虫根本不会遵守，浏览器也不会因为 robots.txt 禁止就阻止你访问某个页面。它约束的是搜索引擎这类守规矩的抓取程序。做网站的人经常在这上面犯一个错误：想把某个页面“藏起来”，于是在 robots.txt 里 Disallow，但真遇到恶意抓取根本没用。想真正保护数据，得靠身份认证和访问控制，而不是 robots.txt。
7. 常见 HTTP 问题排查与处理实录
7.1 400 类错误：先检查请求本身
排查 400 错误，我的习惯是先把请求原样打出来。用 curl 的时候加 -v 参数，用浏览器 F12 打开 Network 面板复制 Curl 格式的请求，最重要的是确认三件事：URL 编码是否正确、Content-Type 跟请求体是否匹配、参数类型是否对得上。
举个例子，搜索词里有一条报错信息跟 AI 接口相关，原因是分块传输时的 reasoning_content 字段没有被原样带回。这种问题本质上就是参数协议不一致：服务端要求某个字段必须存在、格式必须正确，客户端没按约定来，服务器直接 400 拒绝。排查的办法就是逐字段比对接口文档，别猜。
JSON 嵌套层次过深也会导致解析失败。很多 JSON 解析库默认有最大嵌套深度限制，一般 64 层或 128 层。如果业务确实需要深层次嵌套，要么改数据结构，要么调整解析器的深度限制。
7.2 401/403：认证与授权分开查
401 和 403 经常被混为一谈，其实区别很大。401 是“我不知道你是谁”，403 是“我知道你是谁但你没权限”。排查 401 的时候重点看认证凭证：Authorization 头带了没有、token 过期没有、签名算法对不对。而 403 就要看权限模型了：角色的权限配置、资源所有人判断、IP 白名单、防盗链规则，都可能导致 403。
实际运维中还有一种很隐蔽的 403：服务器所在网络出口 IP 被目标服务的防火墙封了，或者被 WAF 判定为恶意请求。这种时候请求本身没问题，就是网络层面的访问策略拦截了。
7.3 500/502/503/504：服务端故障的排查梯度
5xx 错误排在第一位的是 500 Internal Server Error，通常表示应用代码跑崩了。看应用日志是第一步，如果日志里没有明显异常，可能是异常被吞了，也可能是 OutOfMemory、线程池耗尽这种 JVM 层面的问题，需要看监控指标。
502 Bad Gateway 是反向代理连不上上游应用，或者上游返回的响应头不合法。常见原因：应用进程崩溃、端口被占用、防火墙拦截、上游响应超时。排查时先 curl 直接访问上游应用地址，看应用本身通不通；再检查 Nginx 的配置，看 upstream 里写的端口有没有配错。
503 Service Unavailable 表示服务器当前无法处理请求，常见于应用启动中、执行了停机操作、或者限流策略生效。504 Gateway Timeout 则是网关等待上游响应超时，如果上游处理请求确实需要很长时间，可以考虑调大 proxy_read_timeout，但更根本的是优化上游接口性能。
搜索词里有一条 Docker 报错：
code复制error response from daemon: get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection
这是典型的拉镜像时网络连接被取消，原因可能是网络不稳定、代理配置异常、或者镜像源被墙。解决思路是换一个可达的镜像加速器，或者检查本机代理设置，确保 docker 守护进程能访问外网。
7.4 连接失败类错误：000、连接被拒绝、超时
conda 报过 HTTP 000 CONNECTION FAILED for url <https://repo.anaconda.com/...>，这一类错误共同特征是“连接都建立不起来”，跟 HTTP 应用层的关系不大，纯粹是网络层问题。排查顺序是：先 ping 域名看通不通，再 telnet 域名 443 看端口通不通，再 curl -v 看是 DNS 解析失败、TCP 连接被拒绝还是 TLS 握手超时。
VSCode、各种 IDE 里报 502 或 10061 也经常是同一类问题。10061 是 Windows 上常见的“目标计算机积极拒绝连接”，说明本机端口根本没有服务监听。报错信息里出现 http://127.0.0.1 这种本机地址时，基本可以确认是本地某个插件、代理、扩展服务没有正常启动。解决办法是先检查对应端口进程是否存在，再考虑重启相关服务。
8. 给你的调试工具箱与日常习惯
说几个我一直保留的工作习惯，这些不是文档里的理论，是我踩坑踩出来的。
第一，任何接口问题先跑一次 curl -v。它能显示请求的完整过程：DNS 解析、TCP 连接、TLS 握手、请求头、响应头、响应体。很多问题一眼就能看出来，比如证书过期、重定向循环、响应头 Content-Type 不对、被中间层拦截。
bash复制curl -v https://api.example.com/v1/users
如果请求要带 JSON 数据，用：
bash复制curl -X POST https://api.example.com/v1/login \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"username":"admin","password":"123456"}'
第二，把超时时间当成接口调用的必填参数。我见过无数因为“没设超时”导致的故障：一个外部接口挂了，调用线程全部卡在等待响应上，最终拖垮了整个服务。ConnectTimeout 和 ReadTimeout 一定要分开设置，连接超时短一点，比如 3 秒，读超时根据业务特点设置，一般 5 到 10 秒。
第三，日志里永远记录 HTTP 状态码和响应时间。业务日志只记“成功”“失败”远远不够，状态码能帮你快速区分是客户端问题、服务端问题还是网络问题。响应时间不达标的接口也要纳入监控，很多故障不是突然发生的，是缓慢劣化的。
第四，区分幂等操作还是不幂等操作，设计重试策略时格外小心。POST 请求本质上不是幂等的，如果接口超时就直接重试，可能会导致数据重复创建。这时候要么让接口支持幂等键（Idempotency-Key），要么用 PUT 替代 POST，要么在业务层面做去重。
第五，别忽视响应头里的缓存策略。HTTP 响应头里的 Cache-Control、Expires、ETag 是控制浏览器和 CDN 缓存的关键。接口数据如果允许缓存，配置得当能显著降低服务器压力；如果不允许缓存，记得显式设置 Cache-Control: no-store，否则可能因为浏览器缓存导致用户看不到最新数据。
第六，多了解一点同类的网络协议，但没必要全精通。TCP/IP 必须懂，这是基础；DNS、TLS、WebSocket、HTTP/2、HTTP/3 值得了解；MQTT 在物联网场景里经常代替 HTTP，至少要能判断什么时候该用它；CAN、Modbus、NMEA 这类行业协议，等你真接触对应领域的时候再深入也不迟。
我自己刚开始学 HTTP 的时候，也是被各种概念砸得头晕：请求、响应、状态码、连接池、TLS、证书、代理、缓存，每个词背后都是一套体系。但用久了你会发现，HTTP 真正的难点不是记忆这些名词，而是建立“一次请求从客户端到服务器完整走一遍，中间每一环都有什么特征、每种异常对应哪一层”的思维模型。
心态上放平，先从最常见的 200、301、400、401、404、500、502 这几个状态码入手，每个都在真实项目里亲自查一遍，比看十遍教程都管用。等你哪天真能看着一行报错就能猜出是协议格式问题、网络问题还是服务端问题，你就已经超过不少工作三五年的人了。