前后端联调的时候你盯着浏览器开发者工具里的 Network 面板发愣明明接口地址是对的怎么就一直 404别人机器上正常的页面到自己电脑上样式全丢、JS 报错。绝大多数新手栽在这些问题上不是因为代码写得少而是看不明白 HTTP 请求和响应里到底写了什么。Day 31 这个节点刚好是从会写页面跨到能独立排查问题的关键一步今天就把 HTTP 协议里的请求、响应、状态码、请求头一次讲透不讲虚的全是实操时用得上的东西。1. 为什么入门 Web 开发要先理解 HTTP1.1 HTTP 是 Web 世界的通用语言把 HTTP 想象成快递系统你是发件人服务器是收件人HTTP 请求就是你填好的快递单和包裹HTTP 响应就是对方签收后回给你的凭证和回礼。浏览器、手机 App、小程序只要是联网拿数据底层跑的都是 HTTP。你用的框架再高级最终在网络上传输的也不过是符合 HTTP 规则的一串文本。很多新手觉得这是后端才需要懂的东西其实完全不是这么回事——前端写接口调用、调试页面报错、处理登录态、排查线上问题哪一样都绕不开对 HTTP 的理解。我见过不少同学前端页面写得挺溜一遇到接口报错就懵。问他报什么错他说就是报错啊反正是红的。打开开发者工具一看状态码 500响应体里写着 NullPointerException他却不知道这已经是最明确的线索了。这不是能力问题是缺少对 HTTP 这套规则的整体认知。把 HTTP 搞明白等于在脑子里装了一张 Web 世界的交通地图以后所有的排查工作都是在看我现在堵在哪个路口。1.2 学透 HTTP 能解决什么实际问题面试的时候HTTP 几乎是必考题。请求方法、状态码、请求头这些概念看上去是八股文但面试官真正想听的是你有没有在实际项目里用过它们。比如问你 GET 和 POST 的区别你要是只会背GET 拿数据、POST 提交数据那基本就凉了一半。真正有经验的人会告诉你GET 的请求参数会暴露在 URL 上不适合传密码GET 是幂等的POST 不是在某些网关和浏览器环境下URL 长度有上限所以大文件上传必须用 POST。这些细节全是实际踩坑踩出来的。日常开发里HTTP 知识最直接的价值是加快排查速度。页面白屏了先看 Network 面板里资源有没有加载出来接口报错了先看状态码是 4xx 还是 5xx请求被拦了先看是不是跨域问题。这些东西如果不懂就只能到处瞎猜甚至把后端代码翻个底朝天结果问题出在请求头少传了一个参数。把 HTTP 理解透你会发现排查问题是有明确路径的不是靠运气的。2. 请求客户端是怎么说话的2.1 请求行三个要素缺一不可一次 HTTP 请求的开头是一行请求行它规定了这次请求最核心的三个信息请求方法、请求目标、HTTP 版本。GET /api/user/1001 HTTP/1.1这里 GET 是方法/api/user/1001 是请求目标HTTP/1.1 是协议版本。很多新手会好奇为什么请求目标只写了路径不写完整的域名因为域名放在了下面一行的 Host 请求头里。一个服务器上可能部署着好几个站点HTTP/1.1 时代开始强制要求 Host 头目的就是让服务器知道客户端想访问的是哪一个虚拟主机。协议版本也别忽略。目前绝大多数场景还是 HTTP/1.1HTTP/2 在慢慢普及。版本不同请求的写法、连接的复用方式都有差异。比如 HTTP/1.1 的连接默认是 keep-alive 的避免了每次请求都重新建立 TCP 连接HTTP/2 更进一步把多个请求复用在一个连接上。调试的时候偶尔会看到HTTP/2 403之类的错误这多半跟服务器对协议的限流或配置有关不能完全不认识。2.2 请求方法动词选错问题就大了请求方法本质上是客户端告诉服务器我想干什么。HTTP 协议里定义了一些标准动词日常开发最常用的就这几个方法典型用途请求体幂等性GET查询资源通常无幂等POST新增资源、提交表单有非幂等PUT整体更新资源有幂等PATCH局部更新资源有非幂等DELETE删除资源通常无幂等HEAD只获取响应头无幂等OPTIONS预检请求、探测服务器支持无幂等幂等这个概念很多新手一开始不懂。简单说幂等就是执行一次和执行多次结果一样。你调用一次 GET 和调用十次 GET资源的状态不会变但 POST 多调一次就可能多创建一条数据。所以写代码的时候要注意刷新页面导致表单重复提交往往就是因为提交按钮用的是 POST刷新时浏览器会重新发送请求结果数据库里多了一条重复记录。这也是为什么很多系统会做防止重复提交的处理。还有一点经常被忽略HTML 表单的 method 只支持 GET 和 POST。如果你在表单里写了 methodPUT浏览器实际上会把它当成 GET 处理或者直接不支持这在新手阶段非常容易踩坑。前后端接口文档里写的 PUT用浏览器表单根本模拟不了必须靠工具比如 curl 或专门的接口调试工具来发。2.3 请求头和请求体元信息与正文一个完整的请求长这样POST /api/login HTTP/1.1 Host: api.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Content-Type: application/json Content-Length: 42 {username:demo,password:123456}空行之前的部分是请求头空行之后是请求体。请求头是快递单上的备注告诉服务器这一单是什么性质、有什么要求请求体是包裹里的货物是真正要提交的数据。GET 请求通常没有请求体因为它的目标是要数据而不是送数据数据都放在 URL 查询参数里了。POST、PUT 这类请求一般才有请求体。新手最容易搞混的一点请求头和请求体之间必须有一个空行这是 HTTP 协议的固定格式。如果你自己拼 HTTP 报文写底层网络程序时偶尔会干这事漏了空行服务器解析请求头时会直接懵掉。另外请求头里的 Content-Length 表示请求体的字节数如果这个数值和实际请求体长度不一致服务器可能一直等待数据接收完就表现为请求卡住。请求头的写法也有讲究每一行是字段名: 字段值的格式冒号后面通常有一个空格字段名大小写不敏感。Cookie、Content-Type 这些名字都是约定俗成的别自己发明新字段因为服务器只认标准字段。3. 响应服务器回给我们的答卷3.1 状态行先看这个数字请求发出去之后服务器会返回一个响应。响应的第一行叫状态行包含了 HTTP 版本、状态码、原因短语HTTP/1.1 200 OK这行字里200 是状态码OK 是原因短语。原因短语是对状态码的简短解释主要是给人看的机器真正关心的是状态码本身。看到 200 就知道成功看到 404 就知道资源不存在看到 500 就知道服务器内部出错了。我调试接口的时候第一眼永远看状态行。这不是什么高深技巧而是一种本能反应。状态码能把问题隔离开4xx 开头的大概率是客户端的问题——地址不对、参数不对、没权限5xx 开头的大概率是服务器的问题——程序崩了、数据库连不上、依赖的服务挂了。方向对了排查效率直接翻倍。你想想如果拿到一个 500你不去后端日志里找异常堆栈反而在自己的代码里翻来翻去那不是白费劲吗3.2 响应头和响应体响应体和请求一样在状态行之后是响应头空行之后是响应体。常见的响应头有这些HTTP/1.1 200 OK Content-Type: application/json; charsetutf-8 Content-Length: 57 Cache-Control: no-cache Set-Cookie: sessionIdabc123; Path/Content-Type 告诉你响应体是什么类型。浏览器特别依赖这个字段来决定怎么展示响应如果 Content-Type 是 text/html浏览器就渲染成页面如果是 image/png就渲染成图片如果是 application/json一般就直接展示成纯文本。有一种经典问题就是接口返回的明明是 JSON 数据但 Content-Type 写成了 text/html导致前端拿不到预期结果。这时候先别怀疑前端看看响应头里 Content-Type 对不对。Set-Cookie 是服务器用来给客户端种 Cookie 的。HTTP 本来是无状态的服务器不记得你是谁但通过 Set-Cookie 给浏览器发一个身份凭证浏览器下次请求时带上 Cookie服务器就能认出来了。这里有个细节响应头里可以出现多个 Set-Cookie一个 Set-Cookie 头对应一个 Cookie 字段。很多框架封装的 cookie 操作其实就是帮你拼这些响应头。4. 状态码一眼定位问题在哪一半4.1 五类状态码速查状态码是三位数字第一位数字代表了大的类别类别含义典型例子1xx信息性状态101 Switching Protocols升级 WebSocket 时用2xx成功200 OK、201 Created、204 No Content3xx重定向301 Moved Permanently、302 Found、304 Not Modified4xx客户端错误400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found5xx服务器错误500 Internal Server Error、502 Bad Gateway、503 Service Unavailable记住这个分类规则比死记硬背所有状态码都有用。看到什么状态码先归类再细看具体是哪一种。我面试的时候经常问一个开放题你线上一个接口突然返回 502你会怎么查会的人会先说502 是 Bad Gateway说明是网关层或者反向代理层出了问题后端的真实服务可能挂了或者起了但没来得及注册到网关。这个回答体现的是对状态码分类的深层理解而不是单纯背数字。4.2 高频状态码逐个说说200 OK最常见请求成功。但注意状态码 200 只代表HTTP 层面成功了不代表业务逻辑一定正确。很多项目无论业务成功还是失败都返回 200只在响应体里用 code 字段区分这种做法有利有弊新手要习惯状态码成功 ≠ 业务成功。201 Created一般用于 POST 创建资源的场景表示资源创建成功。RESTful 接口设计里创建成功后返回 201 是更规范的做法很多团队会用 200 代替也能用但不严谨。204 No Content请求成功但没有内容返回。比如删除操作成功之后不需要返回体用 204 很合适。前端如果发现响应是 204就别去解析响应体了根本没有。301 和 302都是重定向。301 是永久重定向浏览器会记住下次直接访问新地址302 是临时重定向每次都要先访问旧地址再跳转。HTTP 转 HTTPS 一般用 301登录后跳转一般用 302。有个坑POST 请求遇到 302 时很多浏览器会丢失请求体导致跳转后的请求变成 GET这个在写登录逻辑时很容易踩到。304 Not Modified协商缓存命中了内容没有变化。这不是错误是服务器告诉浏览器你可以用本地缓存的版本。新手看到 304 以为是出问题了其实是节约流量的正常机制。401 和 403 经常被搞混。401 是未认证意思是你是谁我都不认识需要先登录403 是已认证但没权限意思是我知道你是谁但你不允许访问这个资源。登录后访问管理员接口返回 403就是权限不够。500服务器内部错误。看到这个码问题基本就在后端代码里需要去看后端日志的异常堆栈。502 Bad Gateway网关收到了无效响应。常见场景是 nginx 代理的后端服务崩了或者服务重启期间请求打进来。503 Service Unavailable服务暂时不可用一般是服务器过载或正在维护。5. 请求头逐个拆解每一行都不是白写的5.1 Host、User-Agent、RefererHost 前面已经说了是目标域名加端口。这里再补一个细节Host 里的端口有时候会搞出问题。比如本地开发时后端跑在 8080你用 localhost:8080 访问还好但如果你通过反向代理把 80 端口的请求转发到 8080转发的请求里 Host 可能会被改掉导致后端做域名校验时失败。排查这类问题先看请求头里的 Host 究竟是谁。User-Agent 是客户端的身份说明里面包含了操作系统、浏览器版本等信息。服务器经常用它做不同设备的响应适配。它也经常被用来做简单的爬虫拦截——看到 UA 里带 curl 或 python就返回拒绝访问。不注意这个的话用 curl 调试某些网站接口时会莫名奇妙被拒把 UA 改成浏览器再试就通了。Referer 表示请求是从哪个页面发出的。它有两个常见用途一个是防盗链比如图片服务器只允许自己域名下的页面引用图片Referer 不对就拒绝另一个是统计来源看看流量是从哪个渠道进来的。注意 Referer 是个敏感头会泄漏用户的上一个页面所以现代浏览器已经有策略在部分场景下不发送 Referer 了别把业务逻辑完全依赖在它上面。5.2 内容协商Accept 与 Content-TypeAccept 系列请求头用于内容协商简单说就是客户端告诉服务器我能接受什么格式的内容。Accept能接受的媒体类型比如 Accept: application/json 表示只想拿 JSON。Accept-Language能接受的语言比如 zh-CN 还是 en-US。Accept-Encoding能接受的压缩格式比如 gzip、br。服务器看到它才会决定要不要压缩响应体。有经验的开发者都知道浏览器请求里一般都会带 Accept-Encoding: gzip, deflate, br所以响应体是压缩过的。如果你用 curl 直接请求接口看到一堆乱码很可能只是没带 Accept-Encoding服务器返回的是原样数据或者带了但没自动解压。Content-Type 是另一个方向的它是在请求体里告诉服务器我发的数据是什么格式。前后端联调时最经典的报错就是用错了 Content-Type——前端用表单格式提交后端却按 JSON 解析解析失败直接报 400。常见的几个值application/x-www-form-urlencoded表单键值对被 URL 编码、multipart/form-data文件上传、application/jsonJSON 字符串。5.3 身份与状态Cookie、Authorization这两个头是处理登录态的。先说 Cookie它是由浏览器管理的JavaScript 里也可以通过 document.cookie 读写但是设置了 HttpOnly 的 Cookie 脚本读不到只能随请求自动发送。客户端每次请求时浏览器会把符合当前域名和路径规则的 Cookie 放在请求头里发给服务器。服务端就靠这个识别你是之前的那个用户。Authorization 是另一种携带身份信息的方式最常用的是放 token。写法一般是 Authorization: Bearer 。和 Cookie 相比token 方案更灵活前后端分离的项目里几乎都是用它。带 token 的请求有个特点token 不会自动带上需要前端代码里手动从存储里取出来放进请求头。所以为什么请求 401这类问题第一个检查点就是请求头里 Authorization 有没有带对。这里给新手一个忠告Cookie 和 Authorization 都等于你的身份凭证千万别把它们打进日志里也千万别放在请求 URL 上。一旦泄漏等于把账号密码送给了别人。很多真实的事故就是日志里打印了请求头结果 token 跟着日志一起被传走了。5.4 缓存控制Cache-Control、If-Modified-Since、ETag缓存相关的头是站内静态资源加载性能的关键。Cache-Control 是其中最核心的一个它可以出现在请求头里也可以出现在响应头里。响应头里的 Cache-Control: max-age3600 表示这个资源在 3600 秒内可以直接用本地缓存不需要重新请求。no-cache 的意思是每次使用前都要问一下服务器资源有没有变不是完全不用缓存no-store 才是真正的完全不缓存。浏览器在验证缓存时会发出条件请求带上 If-Modified-Since 或 If-None-Match。服务器根据资源的修改时间或 ETag 判断是否需要重新返回内容如果没变就返回 304 和空的响应体如果变了就返回 200 和新内容。这套机制很值得新手亲手验证一次。打开一个访问过的页面刷新一下再清空缓存刷新一下对比两次请求的响应状态码就会发现缓存命中的 304 和完整加载的 200 差别非常大。6. 实操亲手抓一次真实的 HTTP 请求6.1 用 curl 观察完整链路纸上谈兵没用最好动手看一眼真实的 HTTP。curl 是一个命令行工具几乎所有系统都自带它发 HTTP 请求特别好使。最常用的排查参数是 -v它会输出完整的请求和响应信息curl -v https://api.example.com/api/user/1001输出大致如下* Connected to api.example.com GET /api/user/1001 HTTP/1.1 Host: api.example.com User-Agent: curl/8.0.1 Accept: */* HTTP/1.1 200 OK Content-Type: application/json; charsetutf-8 Content-Length: 57 {id:1001,name:demo,role:admin}大于号开头的行是请求的内容小于号开头的行是响应的内容。第一次看到这个输出的时候HTTP 协议的整个面貌就非常直观了请求行、请求头、空行、响应状态、响应头、响应体全部明明白白摆在那里。再举一个带请求体的例子。调试登录接口时经常需要用 POST 提交 JSONcurl -X POST https://api.example.com/api/login \ -H Content-Type: application/json \ -d {username:demo,password:123456} \ -v这样就能完整看到 POST 请求的请求行、Content-Type、请求体和服务器返回。我调试后端接口的第一动作永远是 curl因为它能完全脱离浏览器环境排除掉浏览器插件、缓存、跨域策略带来的干扰看到最纯粹的 HTTP 交互。如果 curl 返回结果是对的但页面请求不对那问题大概率出在浏览器端或者前端代码上范围一下就缩小了。6.2 浏览器开发者工具 Network 面板日常前端开发用浏览器开发者工具更顺手。打开方式很简单页面里按 F12切到 Network 面板刷新页面就能看到页面的每一次请求。这个面板就是新手的照妖镜能照出一堆问题。看请求主要看几个地方Headers 标签页能看到请求头、响应头、请求路径、状态码。注意这里有个 View Source 的选项可以看到原始报文比格式化视图更准确。Payload 标签页能看到请求体内容POST 请求提交的数据长什么样一目了然。Preview 和 Response 标签页能看到响应内容。Preview 是格式化后的Response 是原始文本。Timing 标签页能看到这个请求从开始到结束每个阶段的耗时比如 DNS 解析、连接建立、等待响应、下载内容。接口慢到底慢在哪一步这个页面会告诉你。有个使用技巧Network 面板的筛选框里可以按 Fetch/XHR 过滤这样只显示接口请求不显示图片、CSS 这些静态资源。排查接口问题时先做这个过滤页面就不会被一堆资源请求淹没。另外勾选 Preserve log保留日志可以在页面跳转时保留之前的请求记录排查登录跳转问题特别有用——很多请求在页面跳转后就没了不勾选根本看不到。7. 常见问题与排查技巧实录7.1 状态码 200但页面就是不对这种情况最迷惑人。HTTP 状态是 200说明请求成功返回了但页面白屏或者显示不对。先看响应体浏览器开发者工具里切换到 Response 标签看看服务器到底返回了什么。如果返回的是 JSON 数据但你的前端期望的是 HTML那问题就在路由配置上——你可能请求错了 URL但后端有个兜底路由把它当成功处理了。如果是静态资源返回 200 但内容不对比如明明请求 JS 却返回了 HTML大概率是服务器配置了单页应用的重写规则把所有路径都指到了 index.html。这时候浏览器拿到了错误的文件自然执行不了。这类问题的排查思路就是永远先看响应体别只看状态码。状态码只代表这个请求被处理了不代表处理得对。7.2 接口 404但服务明明在跑404 是最常见的报错原因却有好几种。第一种是路径写错了比如多了个斜杠、少了个前缀。有些项目的接口统一带 /api 前缀有些没有文档里写得清清楚楚但手一抖就漏了。第二种是项目上下文路径的问题部署时应用挂在一个子路径下比如 /myapp那请求路径也要带上这个前缀。第三种是方法用错了比如接口要求 POST你用 GET 去请求有些框架会返回 405 Method Not Allowed但也有一些网关会映射到 404让人摸不着头脑。排查 404 有个固定流程先用 curl 直接请求这个地址排除浏览器因素然后用开发者工具看请求落到了哪个完整 URL和接口文档逐一对比如果 URL 没错再去后端日志里看有没有对应的路由匹配记录。按这个顺序走绝大多数 404 几分钟就能定位。7.3 一调接口就报跨域错误Access-Control-Allow-Origin 这几个字几乎每个前端都见过。跨域是浏览器的安全机制默认情况下网页里的 JavaScript 只能请求同源协议、域名、端口都相同的资源。你本地开发时前端跑在 localhost:3000后端跑在 localhost:8080端口不同这就是跨域。解决方式有很多后端在响应头里加 Access-Control-Allow-Origin开发环境配代理转发JSONP只支持 GET等等。新手最常见的困惑是用 curl 请求没问题浏览器里就报跨域怀疑是后端没做。这里有个关键点要懂——跨域是浏览器拦截的curl 没有浏览器同源策略所以不受影响。还有跨域请求如果是非简单请求浏览器会先发一个 OPTIONS 的预检请求去探服务器允不允许。所以后端接口如果没处理好 OPTIONS 请求浏览器会报预检失败。排查跨域问题时在 Network 里看到红色的 OPTIONS 请求基本就是这条链路。7.4 中文乱码到底是谁的锅乱码问题本质上就是编码不一致。服务器按 UTF-8 输出页面按 GBK 解析那必然乱。排查时先看响应头里的 Content-Type 怎么写的如果写的是 charsetutf-8而页面的字符集设置却是别的那问题在页面如果响应头根本没写 charset那浏览器只能猜就容易猜错。还有一种场景是数据库读出来的中文乱码那是另一层的问题——数据库连接 URL 里没加 characterEncoding。不管哪一层排查思路都是沿着数据怎么存的、怎么传的、怎么渲染的这条链路逐个检查编码配置。我给个最简单的方法用 curl 把接口响应抓下来用文本工具看一眼原始字节乱不乱码一目了然。如果 curl 也是乱码问题在服务器端如果 curl 正常但页面上乱问题在浏览器解析环节。为了方便以后排查我把最常见的几类问题整理成一张速查表现象优先检查点涉及的头/字段接口 404路径前缀、方法、上下文路径请求行登录后仍 401请求头是否带 Authorization 或 CookieAuthorization、Cookie接口报 403账号权限、IP 白名单无提交数据后报 400Content-Type 与后端解析方式是否一致Content-Type页面资源缓存不更新Cache-Control、ETag 配置Cache-Control、ETag跨域报错后端是否允许该源、OPTIONS 预检Origin、Access-Control-Allow-Origin中文乱码响应 charset、数据库连接编码Content-Type8. 我的几条实战心得写到这里再啰嗦几句这些年总结出来的习惯。第一遇到任何请求问题先用 curl 脱离浏览器复现一遍。这一步能帮你快速区分是浏览器环境的问题还是真的接口有问题省掉大量无意义的争论。第二读 Network 面板要养成固定顺序先看状态码归类再看请求头参数齐不齐最后看响应体内容。顺序对了思路就不会乱。第三别怕手动拼请求。很多框架帮你把请求都封装好了导致新手没见过裸 HTTP 是什么样子。找机会用 curl 手写一次带 JSON 的 POST 请求你对 HTTP 的理解会上一个台阶。HTTP 协议本身不复杂它的复杂在于和实际工程结合在一起。希望你今天看完这篇文章不只是记住了几个状态码而是真正能看懂 Network 面板里每一行请求、每一个字段的含义。这才是从会写代码到会查问题的关键一步。最后再分享一个小技巧开发的时候给浏览器装一个可以查看和编辑请求头的扩展工具。当你需要在请求里临时加一个调试用的头部时比如模拟特定用户身份它能帮你在几秒钟内完成修改而不需要改代码重新部署。这个小习惯能让你在联调和排查问题时比别人快一大截。
前后端联调的时候你盯着浏览器开发者工具里的 Network 面板发愣明明接口地址是对的怎么就一直 404别人机器上正常的页面到自己电脑上样式全丢、JS 报错。绝大多数新手栽在这些问题上不是因为代码写得少而是看不明白 HTTP 请求和响应里到底写了什么。Day 31 这个节点刚好是从会写页面跨到能独立排查问题的关键一步今天就把 HTTP 协议里的请求、响应、状态码、请求头一次讲透不讲虚的全是实操时用得上的东西。1. 为什么入门 Web 开发要先理解 HTTP1.1 HTTP 是 Web 世界的通用语言把 HTTP 想象成快递系统你是发件人服务器是收件人HTTP 请求就是你填好的快递单和包裹HTTP 响应就是对方签收后回给你的凭证和回礼。浏览器、手机 App、小程序只要是联网拿数据底层跑的都是 HTTP。你用的框架再高级最终在网络上传输的也不过是符合 HTTP 规则的一串文本。很多新手觉得这是后端才需要懂的东西其实完全不是这么回事——前端写接口调用、调试页面报错、处理登录态、排查线上问题哪一样都绕不开对 HTTP 的理解。我见过不少同学前端页面写得挺溜一遇到接口报错就懵。问他报什么错他说就是报错啊反正是红的。打开开发者工具一看状态码 500响应体里写着 NullPointerException他却不知道这已经是最明确的线索了。这不是能力问题是缺少对 HTTP 这套规则的整体认知。把 HTTP 搞明白等于在脑子里装了一张 Web 世界的交通地图以后所有的排查工作都是在看我现在堵在哪个路口。1.2 学透 HTTP 能解决什么实际问题面试的时候HTTP 几乎是必考题。请求方法、状态码、请求头这些概念看上去是八股文但面试官真正想听的是你有没有在实际项目里用过它们。比如问你 GET 和 POST 的区别你要是只会背GET 拿数据、POST 提交数据那基本就凉了一半。真正有经验的人会告诉你GET 的请求参数会暴露在 URL 上不适合传密码GET 是幂等的POST 不是在某些网关和浏览器环境下URL 长度有上限所以大文件上传必须用 POST。这些细节全是实际踩坑踩出来的。日常开发里HTTP 知识最直接的价值是加快排查速度。页面白屏了先看 Network 面板里资源有没有加载出来接口报错了先看状态码是 4xx 还是 5xx请求被拦了先看是不是跨域问题。这些东西如果不懂就只能到处瞎猜甚至把后端代码翻个底朝天结果问题出在请求头少传了一个参数。把 HTTP 理解透你会发现排查问题是有明确路径的不是靠运气的。2. 请求客户端是怎么说话的2.1 请求行三个要素缺一不可一次 HTTP 请求的开头是一行请求行它规定了这次请求最核心的三个信息请求方法、请求目标、HTTP 版本。GET /api/user/1001 HTTP/1.1这里 GET 是方法/api/user/1001 是请求目标HTTP/1.1 是协议版本。很多新手会好奇为什么请求目标只写了路径不写完整的域名因为域名放在了下面一行的 Host 请求头里。一个服务器上可能部署着好几个站点HTTP/1.1 时代开始强制要求 Host 头目的就是让服务器知道客户端想访问的是哪一个虚拟主机。协议版本也别忽略。目前绝大多数场景还是 HTTP/1.1HTTP/2 在慢慢普及。版本不同请求的写法、连接的复用方式都有差异。比如 HTTP/1.1 的连接默认是 keep-alive 的避免了每次请求都重新建立 TCP 连接HTTP/2 更进一步把多个请求复用在一个连接上。调试的时候偶尔会看到HTTP/2 403之类的错误这多半跟服务器对协议的限流或配置有关不能完全不认识。2.2 请求方法动词选错问题就大了请求方法本质上是客户端告诉服务器我想干什么。HTTP 协议里定义了一些标准动词日常开发最常用的就这几个方法典型用途请求体幂等性GET查询资源通常无幂等POST新增资源、提交表单有非幂等PUT整体更新资源有幂等PATCH局部更新资源有非幂等DELETE删除资源通常无幂等HEAD只获取响应头无幂等OPTIONS预检请求、探测服务器支持无幂等幂等这个概念很多新手一开始不懂。简单说幂等就是执行一次和执行多次结果一样。你调用一次 GET 和调用十次 GET资源的状态不会变但 POST 多调一次就可能多创建一条数据。所以写代码的时候要注意刷新页面导致表单重复提交往往就是因为提交按钮用的是 POST刷新时浏览器会重新发送请求结果数据库里多了一条重复记录。这也是为什么很多系统会做防止重复提交的处理。还有一点经常被忽略HTML 表单的 method 只支持 GET 和 POST。如果你在表单里写了 methodPUT浏览器实际上会把它当成 GET 处理或者直接不支持这在新手阶段非常容易踩坑。前后端接口文档里写的 PUT用浏览器表单根本模拟不了必须靠工具比如 curl 或专门的接口调试工具来发。2.3 请求头和请求体元信息与正文一个完整的请求长这样POST /api/login HTTP/1.1 Host: api.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Content-Type: application/json Content-Length: 42 {username:demo,password:123456}空行之前的部分是请求头空行之后是请求体。请求头是快递单上的备注告诉服务器这一单是什么性质、有什么要求请求体是包裹里的货物是真正要提交的数据。GET 请求通常没有请求体因为它的目标是要数据而不是送数据数据都放在 URL 查询参数里了。POST、PUT 这类请求一般才有请求体。新手最容易搞混的一点请求头和请求体之间必须有一个空行这是 HTTP 协议的固定格式。如果你自己拼 HTTP 报文写底层网络程序时偶尔会干这事漏了空行服务器解析请求头时会直接懵掉。另外请求头里的 Content-Length 表示请求体的字节数如果这个数值和实际请求体长度不一致服务器可能一直等待数据接收完就表现为请求卡住。请求头的写法也有讲究每一行是字段名: 字段值的格式冒号后面通常有一个空格字段名大小写不敏感。Cookie、Content-Type 这些名字都是约定俗成的别自己发明新字段因为服务器只认标准字段。3. 响应服务器回给我们的答卷3.1 状态行先看这个数字请求发出去之后服务器会返回一个响应。响应的第一行叫状态行包含了 HTTP 版本、状态码、原因短语HTTP/1.1 200 OK这行字里200 是状态码OK 是原因短语。原因短语是对状态码的简短解释主要是给人看的机器真正关心的是状态码本身。看到 200 就知道成功看到 404 就知道资源不存在看到 500 就知道服务器内部出错了。我调试接口的时候第一眼永远看状态行。这不是什么高深技巧而是一种本能反应。状态码能把问题隔离开4xx 开头的大概率是客户端的问题——地址不对、参数不对、没权限5xx 开头的大概率是服务器的问题——程序崩了、数据库连不上、依赖的服务挂了。方向对了排查效率直接翻倍。你想想如果拿到一个 500你不去后端日志里找异常堆栈反而在自己的代码里翻来翻去那不是白费劲吗3.2 响应头和响应体响应体和请求一样在状态行之后是响应头空行之后是响应体。常见的响应头有这些HTTP/1.1 200 OK Content-Type: application/json; charsetutf-8 Content-Length: 57 Cache-Control: no-cache Set-Cookie: sessionIdabc123; Path/Content-Type 告诉你响应体是什么类型。浏览器特别依赖这个字段来决定怎么展示响应如果 Content-Type 是 text/html浏览器就渲染成页面如果是 image/png就渲染成图片如果是 application/json一般就直接展示成纯文本。有一种经典问题就是接口返回的明明是 JSON 数据但 Content-Type 写成了 text/html导致前端拿不到预期结果。这时候先别怀疑前端看看响应头里 Content-Type 对不对。Set-Cookie 是服务器用来给客户端种 Cookie 的。HTTP 本来是无状态的服务器不记得你是谁但通过 Set-Cookie 给浏览器发一个身份凭证浏览器下次请求时带上 Cookie服务器就能认出来了。这里有个细节响应头里可以出现多个 Set-Cookie一个 Set-Cookie 头对应一个 Cookie 字段。很多框架封装的 cookie 操作其实就是帮你拼这些响应头。4. 状态码一眼定位问题在哪一半4.1 五类状态码速查状态码是三位数字第一位数字代表了大的类别类别含义典型例子1xx信息性状态101 Switching Protocols升级 WebSocket 时用2xx成功200 OK、201 Created、204 No Content3xx重定向301 Moved Permanently、302 Found、304 Not Modified4xx客户端错误400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found5xx服务器错误500 Internal Server Error、502 Bad Gateway、503 Service Unavailable记住这个分类规则比死记硬背所有状态码都有用。看到什么状态码先归类再细看具体是哪一种。我面试的时候经常问一个开放题你线上一个接口突然返回 502你会怎么查会的人会先说502 是 Bad Gateway说明是网关层或者反向代理层出了问题后端的真实服务可能挂了或者起了但没来得及注册到网关。这个回答体现的是对状态码分类的深层理解而不是单纯背数字。4.2 高频状态码逐个说说200 OK最常见请求成功。但注意状态码 200 只代表HTTP 层面成功了不代表业务逻辑一定正确。很多项目无论业务成功还是失败都返回 200只在响应体里用 code 字段区分这种做法有利有弊新手要习惯状态码成功 ≠ 业务成功。201 Created一般用于 POST 创建资源的场景表示资源创建成功。RESTful 接口设计里创建成功后返回 201 是更规范的做法很多团队会用 200 代替也能用但不严谨。204 No Content请求成功但没有内容返回。比如删除操作成功之后不需要返回体用 204 很合适。前端如果发现响应是 204就别去解析响应体了根本没有。301 和 302都是重定向。301 是永久重定向浏览器会记住下次直接访问新地址302 是临时重定向每次都要先访问旧地址再跳转。HTTP 转 HTTPS 一般用 301登录后跳转一般用 302。有个坑POST 请求遇到 302 时很多浏览器会丢失请求体导致跳转后的请求变成 GET这个在写登录逻辑时很容易踩到。304 Not Modified协商缓存命中了内容没有变化。这不是错误是服务器告诉浏览器你可以用本地缓存的版本。新手看到 304 以为是出问题了其实是节约流量的正常机制。401 和 403 经常被搞混。401 是未认证意思是你是谁我都不认识需要先登录403 是已认证但没权限意思是我知道你是谁但你不允许访问这个资源。登录后访问管理员接口返回 403就是权限不够。500服务器内部错误。看到这个码问题基本就在后端代码里需要去看后端日志的异常堆栈。502 Bad Gateway网关收到了无效响应。常见场景是 nginx 代理的后端服务崩了或者服务重启期间请求打进来。503 Service Unavailable服务暂时不可用一般是服务器过载或正在维护。5. 请求头逐个拆解每一行都不是白写的5.1 Host、User-Agent、RefererHost 前面已经说了是目标域名加端口。这里再补一个细节Host 里的端口有时候会搞出问题。比如本地开发时后端跑在 8080你用 localhost:8080 访问还好但如果你通过反向代理把 80 端口的请求转发到 8080转发的请求里 Host 可能会被改掉导致后端做域名校验时失败。排查这类问题先看请求头里的 Host 究竟是谁。User-Agent 是客户端的身份说明里面包含了操作系统、浏览器版本等信息。服务器经常用它做不同设备的响应适配。它也经常被用来做简单的爬虫拦截——看到 UA 里带 curl 或 python就返回拒绝访问。不注意这个的话用 curl 调试某些网站接口时会莫名奇妙被拒把 UA 改成浏览器再试就通了。Referer 表示请求是从哪个页面发出的。它有两个常见用途一个是防盗链比如图片服务器只允许自己域名下的页面引用图片Referer 不对就拒绝另一个是统计来源看看流量是从哪个渠道进来的。注意 Referer 是个敏感头会泄漏用户的上一个页面所以现代浏览器已经有策略在部分场景下不发送 Referer 了别把业务逻辑完全依赖在它上面。5.2 内容协商Accept 与 Content-TypeAccept 系列请求头用于内容协商简单说就是客户端告诉服务器我能接受什么格式的内容。Accept能接受的媒体类型比如 Accept: application/json 表示只想拿 JSON。Accept-Language能接受的语言比如 zh-CN 还是 en-US。Accept-Encoding能接受的压缩格式比如 gzip、br。服务器看到它才会决定要不要压缩响应体。有经验的开发者都知道浏览器请求里一般都会带 Accept-Encoding: gzip, deflate, br所以响应体是压缩过的。如果你用 curl 直接请求接口看到一堆乱码很可能只是没带 Accept-Encoding服务器返回的是原样数据或者带了但没自动解压。Content-Type 是另一个方向的它是在请求体里告诉服务器我发的数据是什么格式。前后端联调时最经典的报错就是用错了 Content-Type——前端用表单格式提交后端却按 JSON 解析解析失败直接报 400。常见的几个值application/x-www-form-urlencoded表单键值对被 URL 编码、multipart/form-data文件上传、application/jsonJSON 字符串。5.3 身份与状态Cookie、Authorization这两个头是处理登录态的。先说 Cookie它是由浏览器管理的JavaScript 里也可以通过 document.cookie 读写但是设置了 HttpOnly 的 Cookie 脚本读不到只能随请求自动发送。客户端每次请求时浏览器会把符合当前域名和路径规则的 Cookie 放在请求头里发给服务器。服务端就靠这个识别你是之前的那个用户。Authorization 是另一种携带身份信息的方式最常用的是放 token。写法一般是 Authorization: Bearer 。和 Cookie 相比token 方案更灵活前后端分离的项目里几乎都是用它。带 token 的请求有个特点token 不会自动带上需要前端代码里手动从存储里取出来放进请求头。所以为什么请求 401这类问题第一个检查点就是请求头里 Authorization 有没有带对。这里给新手一个忠告Cookie 和 Authorization 都等于你的身份凭证千万别把它们打进日志里也千万别放在请求 URL 上。一旦泄漏等于把账号密码送给了别人。很多真实的事故就是日志里打印了请求头结果 token 跟着日志一起被传走了。5.4 缓存控制Cache-Control、If-Modified-Since、ETag缓存相关的头是站内静态资源加载性能的关键。Cache-Control 是其中最核心的一个它可以出现在请求头里也可以出现在响应头里。响应头里的 Cache-Control: max-age3600 表示这个资源在 3600 秒内可以直接用本地缓存不需要重新请求。no-cache 的意思是每次使用前都要问一下服务器资源有没有变不是完全不用缓存no-store 才是真正的完全不缓存。浏览器在验证缓存时会发出条件请求带上 If-Modified-Since 或 If-None-Match。服务器根据资源的修改时间或 ETag 判断是否需要重新返回内容如果没变就返回 304 和空的响应体如果变了就返回 200 和新内容。这套机制很值得新手亲手验证一次。打开一个访问过的页面刷新一下再清空缓存刷新一下对比两次请求的响应状态码就会发现缓存命中的 304 和完整加载的 200 差别非常大。6. 实操亲手抓一次真实的 HTTP 请求6.1 用 curl 观察完整链路纸上谈兵没用最好动手看一眼真实的 HTTP。curl 是一个命令行工具几乎所有系统都自带它发 HTTP 请求特别好使。最常用的排查参数是 -v它会输出完整的请求和响应信息curl -v https://api.example.com/api/user/1001输出大致如下* Connected to api.example.com GET /api/user/1001 HTTP/1.1 Host: api.example.com User-Agent: curl/8.0.1 Accept: */* HTTP/1.1 200 OK Content-Type: application/json; charsetutf-8 Content-Length: 57 {id:1001,name:demo,role:admin}大于号开头的行是请求的内容小于号开头的行是响应的内容。第一次看到这个输出的时候HTTP 协议的整个面貌就非常直观了请求行、请求头、空行、响应状态、响应头、响应体全部明明白白摆在那里。再举一个带请求体的例子。调试登录接口时经常需要用 POST 提交 JSONcurl -X POST https://api.example.com/api/login \ -H Content-Type: application/json \ -d {username:demo,password:123456} \ -v这样就能完整看到 POST 请求的请求行、Content-Type、请求体和服务器返回。我调试后端接口的第一动作永远是 curl因为它能完全脱离浏览器环境排除掉浏览器插件、缓存、跨域策略带来的干扰看到最纯粹的 HTTP 交互。如果 curl 返回结果是对的但页面请求不对那问题大概率出在浏览器端或者前端代码上范围一下就缩小了。6.2 浏览器开发者工具 Network 面板日常前端开发用浏览器开发者工具更顺手。打开方式很简单页面里按 F12切到 Network 面板刷新页面就能看到页面的每一次请求。这个面板就是新手的照妖镜能照出一堆问题。看请求主要看几个地方Headers 标签页能看到请求头、响应头、请求路径、状态码。注意这里有个 View Source 的选项可以看到原始报文比格式化视图更准确。Payload 标签页能看到请求体内容POST 请求提交的数据长什么样一目了然。Preview 和 Response 标签页能看到响应内容。Preview 是格式化后的Response 是原始文本。Timing 标签页能看到这个请求从开始到结束每个阶段的耗时比如 DNS 解析、连接建立、等待响应、下载内容。接口慢到底慢在哪一步这个页面会告诉你。有个使用技巧Network 面板的筛选框里可以按 Fetch/XHR 过滤这样只显示接口请求不显示图片、CSS 这些静态资源。排查接口问题时先做这个过滤页面就不会被一堆资源请求淹没。另外勾选 Preserve log保留日志可以在页面跳转时保留之前的请求记录排查登录跳转问题特别有用——很多请求在页面跳转后就没了不勾选根本看不到。7. 常见问题与排查技巧实录7.1 状态码 200但页面就是不对这种情况最迷惑人。HTTP 状态是 200说明请求成功返回了但页面白屏或者显示不对。先看响应体浏览器开发者工具里切换到 Response 标签看看服务器到底返回了什么。如果返回的是 JSON 数据但你的前端期望的是 HTML那问题就在路由配置上——你可能请求错了 URL但后端有个兜底路由把它当成功处理了。如果是静态资源返回 200 但内容不对比如明明请求 JS 却返回了 HTML大概率是服务器配置了单页应用的重写规则把所有路径都指到了 index.html。这时候浏览器拿到了错误的文件自然执行不了。这类问题的排查思路就是永远先看响应体别只看状态码。状态码只代表这个请求被处理了不代表处理得对。7.2 接口 404但服务明明在跑404 是最常见的报错原因却有好几种。第一种是路径写错了比如多了个斜杠、少了个前缀。有些项目的接口统一带 /api 前缀有些没有文档里写得清清楚楚但手一抖就漏了。第二种是项目上下文路径的问题部署时应用挂在一个子路径下比如 /myapp那请求路径也要带上这个前缀。第三种是方法用错了比如接口要求 POST你用 GET 去请求有些框架会返回 405 Method Not Allowed但也有一些网关会映射到 404让人摸不着头脑。排查 404 有个固定流程先用 curl 直接请求这个地址排除浏览器因素然后用开发者工具看请求落到了哪个完整 URL和接口文档逐一对比如果 URL 没错再去后端日志里看有没有对应的路由匹配记录。按这个顺序走绝大多数 404 几分钟就能定位。7.3 一调接口就报跨域错误Access-Control-Allow-Origin 这几个字几乎每个前端都见过。跨域是浏览器的安全机制默认情况下网页里的 JavaScript 只能请求同源协议、域名、端口都相同的资源。你本地开发时前端跑在 localhost:3000后端跑在 localhost:8080端口不同这就是跨域。解决方式有很多后端在响应头里加 Access-Control-Allow-Origin开发环境配代理转发JSONP只支持 GET等等。新手最常见的困惑是用 curl 请求没问题浏览器里就报跨域怀疑是后端没做。这里有个关键点要懂——跨域是浏览器拦截的curl 没有浏览器同源策略所以不受影响。还有跨域请求如果是非简单请求浏览器会先发一个 OPTIONS 的预检请求去探服务器允不允许。所以后端接口如果没处理好 OPTIONS 请求浏览器会报预检失败。排查跨域问题时在 Network 里看到红色的 OPTIONS 请求基本就是这条链路。7.4 中文乱码到底是谁的锅乱码问题本质上就是编码不一致。服务器按 UTF-8 输出页面按 GBK 解析那必然乱。排查时先看响应头里的 Content-Type 怎么写的如果写的是 charsetutf-8而页面的字符集设置却是别的那问题在页面如果响应头根本没写 charset那浏览器只能猜就容易猜错。还有一种场景是数据库读出来的中文乱码那是另一层的问题——数据库连接 URL 里没加 characterEncoding。不管哪一层排查思路都是沿着数据怎么存的、怎么传的、怎么渲染的这条链路逐个检查编码配置。我给个最简单的方法用 curl 把接口响应抓下来用文本工具看一眼原始字节乱不乱码一目了然。如果 curl 也是乱码问题在服务器端如果 curl 正常但页面上乱问题在浏览器解析环节。为了方便以后排查我把最常见的几类问题整理成一张速查表现象优先检查点涉及的头/字段接口 404路径前缀、方法、上下文路径请求行登录后仍 401请求头是否带 Authorization 或 CookieAuthorization、Cookie接口报 403账号权限、IP 白名单无提交数据后报 400Content-Type 与后端解析方式是否一致Content-Type页面资源缓存不更新Cache-Control、ETag 配置Cache-Control、ETag跨域报错后端是否允许该源、OPTIONS 预检Origin、Access-Control-Allow-Origin中文乱码响应 charset、数据库连接编码Content-Type8. 我的几条实战心得写到这里再啰嗦几句这些年总结出来的习惯。第一遇到任何请求问题先用 curl 脱离浏览器复现一遍。这一步能帮你快速区分是浏览器环境的问题还是真的接口有问题省掉大量无意义的争论。第二读 Network 面板要养成固定顺序先看状态码归类再看请求头参数齐不齐最后看响应体内容。顺序对了思路就不会乱。第三别怕手动拼请求。很多框架帮你把请求都封装好了导致新手没见过裸 HTTP 是什么样子。找机会用 curl 手写一次带 JSON 的 POST 请求你对 HTTP 的理解会上一个台阶。HTTP 协议本身不复杂它的复杂在于和实际工程结合在一起。希望你今天看完这篇文章不只是记住了几个状态码而是真正能看懂 Network 面板里每一行请求、每一个字段的含义。这才是从会写代码到会查问题的关键一步。最后再分享一个小技巧开发的时候给浏览器装一个可以查看和编辑请求头的扩展工具。当你需要在请求里临时加一个调试用的头部时比如模拟特定用户身份它能帮你在几秒钟内完成修改而不需要改代码重新部署。这个小习惯能让你在联调和排查问题时比别人快一大截。
