面试被问HTTP请求头？别慌，这篇“大白话”带你稳过！
Last updated on February 9, 2026 pm
面试时被问“HTTP常见请求头及作用”，估计是很多后端/前端同学的“常规暴击”。别慌，不是你背得不够熟，而是面试官要的不是“报菜名”，是“懂原理+能落地”的回答。
今天咱们抛开枯燥的背诵清单，用唠嗑的方式把这些请求头扒明白——既能应对面试，以后工作中排坑也能用得上。
必背核心请求头, 面试高频
这几个请求头，要是面试时说不明白，面试官大概率会默默在小本本上画叉。重点不是“是什么”，是“为什么要有”“实际用在哪”。
1. Host：告诉服务器“我找错人了吗？”
写法很简单：Host: www.xxx.com
说白了，它就是告诉服务器你要访问的域名和端口号。别觉得这玩意儿多余——现在很多服务器都是“一个身子扛多个网站”（虚拟主机），比如同一台服务器上既挂着淘宝又挂着天猫，你发请求时不说明要找哪个，服务器哪知道该给你返回淘宝首页还是天猫商城？
面试时别踩这个坑：有同学一上来就说“Host就是指定IP啊”，大错特错！IP是服务器的“小区地址”，Host是服务器上的“单元房号”——你找朋友总不能只说小区名，不说几单元几零几吧？而且HTTP/1.1里，Host是必须带的，少了它，服务器直接给你甩个400错误，请求都发不出去。
实际场景：你在本地调试时，修改hosts文件把域名映射到本地IP，本质就是让客户端发送请求时，Host还是目标域名，但实际访问的是本地服务器——这招前端同学调接口时肯定常用。
2. User-Agent（UA）：客户端的“自我介绍”
举个实际的写法，你打开Chrome浏览器发请求，UA大概长这样：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
服务器拿到这份“自我介绍”，能干两件关键事儿：一是适配不同设备——你用手机打开网站，它就返回移动端页面；用电脑打开，就返回PC端页面，不会让你在手机上看满屏错乱的PC端布局；
二是反爬风控——要是检测到UA是爬虫程序，直接拒绝请求，避免服务器被刷崩。
面试官大概率会追问延伸问题：“怎么通过UA做设备适配？”其实很简单，服务器解析UA字符串，提取出设备类型、浏览器型号，比如识别出是手机端，就返回H5页面；是PC端，就返回Vue/React渲染的页面，精准匹配用户场景。
3. Cookie：客户端的“身份通行证”
日常写法参考：Cookie: username=zhangsan; token=abc123
它最核心的价值，就是解决HTTP“记不住人”的毛病——HTTP是无状态的，服务器根本分不清前后两次请求是不是同一个用户。你第一次登录网站，服务器验证通过后，会给你发一个包含用户信息、token的“通行证”（Cookie），你下次再发请求，自动带上这张证，服务器一看就认出来“哦，是老熟人，不用再登录了”。
开发时很多人都踩过这样的坑：登录后一刷新页面，又要重新登录，大概率就是Cookie出了问题——要么没存住，要么请求时没带上，要么过期时间设得太短，刚登录就失效了。
另外提醒一句，Cookie默认是明文存储的，密码、支付信息这种敏感数据，千万别往里面塞，设置HttpOnly、Secure属性能多一层安全保障。
面试官常追问的“Cookie和Session区别”，一句话就能讲清：Cookie存客户端，Session存服务器；Cookie只装轻量信息（比如token），Session存完整用户状态；Cookie容易被篡改，Session相对更安全。
4. Content-Type：告诉服务器“我发的是啥格式的数据”
最常用的写法比如：Content-Type: application/json
这玩意儿只在POST、PUT这类需要传数据的请求里生效，核心就是跟服务器“打个招呼”：我给你的数据是啥格式，你按这个格式解析就行。
要是没说清，服务器拿到数据也是一脸懵——比如你发的是JSON数据，却没指定类型，服务器可能按表单格式去解析，最后只能返回400错误，白忙活一场。
这几个常用值必须记牢，对应场景一看就懂：
application/x-www-form-urlencoded：表单提交默认格式，数据是key=value&key=value的形式（比如登录时提交账号密码的表单）；application/json：现在接口开发的主流格式，数据是JSON字符串（前后端分离项目基本都用这个）；multipart/form-data：用于文件上传（比如上传头像、附件），能同时传递文件和普通表单数据；text/html：请求体是HTML文档（很少用，一般是返回响应时用）。
5. Authorization：客户端的“身份令牌”
常见写法举例：Authorization: Bearer abc123456
它主要用来做身份验证，相当于给服务器看“我的准入凭证”，证明我有权访问这个资源。和Cookie功能类似，但更灵活——现在很多RESTful API、第三方接口都不用Cookie，直接用它传递token（比如JWT令牌）。
日常开发里，调用微信支付、阿里云这些第三方接口时，都得在请求头里带这个凭证，服务器验证通过了才会返回数据。
还有那些需要登录才能访问的接口（比如查个人订单），登录成功后拿到token，后续每次请求都得带上，不然服务器就会返回401未授权，直接给你拒之门外。
实用辅助请求头
这些请求头不是必传，但实际开发中经常用到，面试时能说出来，会显得你经验很足。
Accept：告诉服务器“我能接收啥格式的响应”
举个例子：Accept: application/json, text/html;q=0.9
简单说，就是客户端跟服务器“提需求”：我能处理的数据格式就这些，你优先给我返回哪种。里面的q是权重（0-1），数字越大优先级越高，上面这个例子就是，优先要JSON格式，实在没有再给HTML格式。
实际场景：有些接口支持返回JSON和XML两种格式，客户端通过Accept指定自己需要的格式，服务器就不会返回无用的格式了。
Cache-Control：告诉服务器“我要怎么缓存”
日常开发里常这么写：Cache-Control: no-cache
它的核心目的就是控缓存，减少无效请求，提升访问速度。几个常用值用大白话解释下：no-cache是“每次都问服务器要新鲜数据，缓存仅作参考”；no-store是“完全不存缓存，每次都从零获取”；max-age=3600是“缓存有效期1小时，1小时内直接用本地的，不用麻烦服务器”。
Referer：告诉服务器“我从哪来”
写法参考：Referer: https://www.baidu.com/
它会告诉服务器“我是从哪个页面跳过来的”。服务器靠这个信息能做两件事：一是防盗链——比如禁止其他网站盗用自己的图片、视频，只允许自家网站引用；二是统计来源——比如看看用户是从百度、朋友圈还是其他渠道进来的，方便做运营分析。
实际场景：你在百度上搜索“微信”，点击链接进入微信官网，此时微信官网的服务器会收到Referer: https://www.baidu.com/，就知道你是从百度来的。
如果有人在自己的网站上引用微信官网的图片，微信服务器通过Referer发现来源不是自己的网站，就会拒绝返回图片（防盗链生效）。
写在最后
其实请求头没那么复杂，核心就是客户端和服务器的“沟通桥梁”——少了它，双方就像鸡同鸭讲，很容易出现请求失败、数据错乱的问题。
日常开发里，Host、UA、Cookie、Content-Type、Authorization这几个是高频必备的，不管是调接口、做适配还是保安全，都离不开它们；Accept、Cache-Control、Referer这些辅助项，则能让请求更高效、更贴合实际需求。
搞懂这些请求头的实际用法，不用死记硬背，后续开发中遇到接口报错、适配异常的问题，就能快速定位原因，少走很多弯路。
【往期精彩】