其实HTTP的“沟通密码”，就藏在这一个个请求头和响应头里。这篇文章把新手必学的常用头字段挑了个遍：从请求头里“告诉服务器你是谁”的User-Agent，到“带什么数据”的Content-Type；从响应头里“让浏览器存Cookie”的Set-Cookie，到“返回什么内容”的Content-Length……每个字段都用直白例子讲清作用，帮你理清“请求-响应”的互动逻辑。不用再查零散资料，不用再猜字段含义——读完这篇，HTTP里最核心的“头信息”，你一次性就能搞懂。
你有没有过这种情况？帮朋友调接口的时候，明明参数都对了，服务器却返回“403禁止访问”；或者打开网站时，明明是手机却显示PC版页面，刷新好几次都没变——其实问题大概率出在HTTP的请求头或响应头上。这俩玩意儿看着是一堆“英文单词+冒号+内容”的字符串，实则是浏览器和服务器之间的“沟通密码”，搞懂它们，你才算真正摸透了HTTP的核心逻辑。
先搞懂：请求头是浏览器发给服务器的“悄悄话”
请求头是什么？简单说就是浏览器在发请求时，偷偷附带给服务器的“备注”——比如“我是谁（用什么浏览器）”“我带了什么数据”“我从哪个页面来的”。这些备注看似不起眼，却直接决定了服务器会不会理你、怎么回应你。我去年帮做美食博客的朋友调过一个接口：他想爬某食材网站的菜谱数据，结果每次请求都被拒，查了半天才发现，他的请求里User-Agent是空的——服务器一看“这玩意儿连自己是谁都不说”，直接当爬虫拦截了。后来我帮他加上了模拟Chrome浏览器的User-Agent，比如Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 Safari/537.36，结果一下就通了。
其实常用的请求头就那么几个，但每一个都有“不可替代的作用”：
sessionid——服务器看到这个ID，就知道“哦，是之前登录的用户张三”。我之前帮电商网站调登录功能时，还遇到过Cookie没设HttpOnly的问题：前端JS能直接读到Cookie里的用户ID，后来改成HttpOnly（只能服务器读写），才算解决了XSS攻击的风险。 application/json）；如果是上传图片，就得说“我发的是文件”（multipart/form-data）。我之前帮朋友做头像上传功能时，就因为把Content-Type写成了application/json，服务器一直收不到文件，折腾了半天才改对。 https://www.baidu.com。有些网站会用Referer做“防盗链”——比如你直接访问某图片的URL，服务器一看Referer不是自己的域名，就返回一张“禁止盗用”的图片，这就是Referer在起作用。 Bearer token放在这里，服务器验证通过了才会给你数据。我之前对接过微信支付的接口，就因为Authorization里的token过期了，连续返回了10次“401未授权”，后来刷新token才解决。 这些请求头为啥重要？因为服务器是“看脸做事”的——它得先通过请求头确认“你是谁、你要干嘛、你有没有资格”，才会处理你的请求。就像你去银行办业务，得先出示身份证（User-Agent）、带好银行卡（Cookie）、说明要办什么业务（Content-Type），柜员才会理你，道理是一样的。
再明白：响应头是服务器给浏览器的“回覆条”
如果说请求头是“浏览器问服务器”，那响应头就是“服务器回答浏览器”——比如“我给你的是什么内容”“你可以把这个内容存多久”“你得跳转到哪个页面”。我之前帮一家教育机构做登录功能时，就遇到过Set-Cookie没设Secure的问题：Cookie是通过HTTP传输的，万一被中间人截获，用户的登录信息就漏了。后来改成Secure（只走HTTPS），才算补上了安全漏洞。
常用的响应头同样“个个有用”：
text/html; charset=utf-8——浏览器一看就知道“哦，我要把这个解析成网页”；返回JSON数据，就是application/json——前端JS就能直接用JSON.parse()解析。我之前帮前端同学调接口时，还遇到过服务器把JSON的Content-Type写成text/plain的情况，结果浏览器把JSON当成纯文本显示，前端报错“无法解析JSON”，改对Content-Type就好了。 Set-Cookie: sessionid=xyz789; HttpOnly; Secure; SameSite=Strict——这里的HttpOnly防止前端JS读取Cookie（防XSS），Secure要求HTTPS传输（防截获），SameSite=Strict禁止跨站请求带Cookie（防CSRF）。这些属性加在一起，才能保证Cookie的安全。 max-age=3600就是“你可以缓存1小时，1小时内不用再问我要”；no-cache不是“不缓存”，而是“缓存可以存，但用之前得问我要不要更新”；no-store才是“不准存，每次都得问我要”。我之前帮博客网站优化时，把CSS、JS这些静态资源的Cache-Control设成max-age=86400（1天），结果页面加载速度从3秒降到了1秒——因为浏览器直接用缓存的资源，不用再请求服务器了。 http://www.baidu.com，服务器会返回Location: https://www.baidu.com（301重定向），浏览器就会自动跳到HTTPS的地址。我之前帮企业做域名迁移时，就用Location把旧域名的流量全导到新域名上，既保证了用户体验，又没影响SEO。 Server: Nginx就是“我是用Nginx服务器跑的”。虽然这个字段不影响功能，但有时候能帮你排查问题——比如你看到Server: Apache，就能知道服务器用的是Apache，查资料时能更有针对性。其实响应头的逻辑很简单：服务器把处理结果“包装”好，再给浏览器发回去——而响应头就是这个“包装纸”上的“标签”，告诉浏览器“怎么处理这个结果”。就像你收到快递时，包装上的“易碎品”“冷藏存储”标签，直接决定了你会怎么处理这个快递，道理一模一样。
为了让你更直观地记住这些常用头，我整理了一张高频请求头&响应头对照表，你可以直接存下来当“速查表”：
| 字段名 | 类型 | 核心作用 | 常见示例 |
|---|---|---|---|
| User-Agent | 请求头 | 告知服务器客户端的浏览器、系统信息 | Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 Safari/537.36 |
| Cookie | 请求头 | 携带用户会话信息（由Set-Cookie设置） | PHPSESSID=abc123; user_id=456 |
| Content-Type | 请求头/响应头 | 请求：告知服务器请求体类型；响应：告知浏览器响应体类型 | application/json（请求/响应）、text/html; charset=utf-8（响应） |
| Set-Cookie | 响应头 | 服务器向浏览器设置Cookie | sessionid=xyz789; HttpOnly; Secure; SameSite=Strict |
| Cache-Control | 响应头 | 控制浏览器缓存策略 | max-age=3600（缓存1小时）、no-cache（需验证缓存） |
这张表你可以存到手机里，遇到问题时翻出来对照——比如下次再遇到“接口请求被拒”，先查User-Agent有没有设；遇到“Cookie丢了”，先查Set-Cookie的属性对不对；遇到“页面加载慢”，先查Cache-Control有没有设缓存时间。
其实HTTP的请求头和响应头，本质上就是“浏览器和服务器的对话规则”——你得按规则“说话”，对方才会“听懂”。我之前接触过很多刚学HTTP的朋友，总觉得“这些头字段不重要，反正框架会自动加”，但真遇到问题时，才发现“框架自动加的不一定对”——比如有些框架默认的User-Agent是“框架名/版本”，很容易被服务器拦截；有些框架的Set-Cookie没设Secure，埋下安全隐患。
最后想跟你说：学HTTP不用背所有头字段，先把这几个常用的搞透就行。你可以试试这个方法：下次调接口时，打开浏览器的“开发者工具”（F12），点“网络”标签，看看每个请求的“请求头”和“响应头”里都有什么——对照着我讲的内容一一对应，用不了多久你就能“一眼看出问题在哪儿”。
你之前有没有遇到过因为请求头或响应头没设对导致的问题？欢迎在评论区告诉我，我帮你分析分析！
本文常见问题（FAQ）
请求头和响应头有什么区别？
请求头是浏览器发给服务器的“悄悄话”，相当于你给服务器递的“备注条”，核心是告诉服务器“我是谁（比如用什么浏览器）、我要发什么数据、我从哪个页面来的”；响应头是服务器回给浏览器的“回复条”，主要是告诉浏览器“我给你的是什么内容、你可以把内容存多久、你得跳转到哪个页面”。简单说就是“浏览器问服务器”和“服务器答浏览器”的本质区别。
比如你打开淘宝，浏览器发请求时带的User-Agent（请求头）是“我是手机Chrome浏览器”，服务器收到后返回的Content-Type（响应头）是“我给你的是手机版HTML页面”——这就是两者的互动逻辑。
User-Agent字段有什么用？为什么有些网站会根据它显示不同页面？
User-Agent是浏览器的“身份证”，会详细告诉服务器你的浏览器型号（比如Chrome/120）、系统版本（比如Windows10）、设备类型（比如手机/PC）。网站根据它调整页面，本质是“适配不同终端”：比如你用手机打开京东，它显示手机版页面，就是因为User-Agent里带了“Mobile”标识；有些网站给老版本IE浏览器返回兼容版页面，也是靠它判断的。
我去年帮朋友爬食材网站数据时，就因为User-Agent是空的被服务器当爬虫拦截，后来加了模拟Chrome的User-Agent（比如Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 Safari/537.36），立马就通了——这就是User-Agent“验证身份”的作用。
Set-Cookie响应头是用来干嘛的？为什么要加HttpOnly、Secure这些属性？
Set-Cookie是服务器给浏览器“发小纸条”的工具，比如你登录知乎成功后，服务器会用Set-Cookie把你的登录会话ID（比如sessionid=xyz789）存到浏览器里，下次你再打开知乎，浏览器会带着这个“小纸条”，服务器一看就知道“是之前登录的用户”，不用你再输密码。
加HttpOnly是为了防止前端JS读取Cookie（避免XSS攻击——比如黑客注入JS偷你登录信息）；加Secure是要求Cookie只能通过HTTPS传输（防止中间人截获）；加SameSite=Strict是禁止跨站请求带Cookie（防CSRF攻击——比如黑客诱导你点恶意链接，用你的Cookie发请求）。这些属性都是为了让Cookie更安全。
Content-Type字段在请求和响应里的作用一样吗？常见的类型有哪些？
作用不太一样，但核心都是“说明数据类型”。请求里的Content-Type是告诉服务器“我要发的是什么类型的数据”——比如你用POST发JSON，得写“application/json”，告诉服务器“我发的是JSON哦”；如果你上传头像（文件），得写“multipart/form-data”，告诉服务器“我发的是文件”。
响应里的Content-Type是告诉浏览器“我给你的是什么内容”——比如服务器返回网页，会写“text/html; charset=utf-8”（浏览器一看就知道要解析成网页）；返回JSON数据，会写“application/json”（前端JS能直接用JSON.parse()解析）。我之前帮朋友做头像上传时，把请求里的Content-Type写成了“application/json”，结果服务器一直收不到文件，改回“multipart/form-data”才解决。
Referer请求头能用来做什么？为什么有些图片直接访问会显示“禁止盗用”？
Referer是告诉服务器“我是从哪个页面跳过来的”——比如你从百度点进某篇文章，Referer就是“https://www.baidu.com”。它最常用的场景是“防盗链”：比如某网站的图片URL是“https://xxx.com/1.jpg”，如果你直接在浏览器里输入这个URL访问，服务器一看Referer不是自己的域名（比如不是“https://xxx.com”），就会返回一张“禁止盗用”的图片，防止别人随便盗用它的图片资源。
我之前帮一家图片网站做防盗链时，就是用Referer判断的——只要Referer不是本站域名或空（比如直接访问），就返回“禁止盗用”的占位图，这样能有效减少图片被滥用的情况。
