企业官网建设流程全解析

面试这个问题问得多了，十个候选人里能有一个答得让人满意的就不错了。倒不是说HTTP请求头有多难，而是大多数人准备面试时都在刷算法、背八股，对这种“看起来太基础”的知识点反而敷衍——结果一问一个坑。

HTTP请求头是面试官很爱用的“试金石”。它看着简单，但能从一个点切开知识面：问Host能聊到虚拟主机和HTTP/1.1的必带字段，问Content-Type能扯到表单提交和文件上传的底层区别，问Origin能绕到跨域和CSRF防护，问Cache-Control能延伸到浏览器缓存策略。面试官根本不是在考你背没背过，而是想看看你能不能从一个字段讲到整个网络知识体系。

这篇文章把面试高频的HTTP请求头拆透，结合我这些年做后端、面试别人、也被别人面试的经验，把每个头的原理、用途、常见踩坑点都讲清楚，最后还会给你一套答题思路和话术示例。不管你是刚准备找实习的在校生，还是打算社招跳槽的开发者，这块内容都值得花一晚上认真过一遍。

1. 面试官问HTTP请求头，到底在考察什么

先说个扎心的事实：面试官问你“HTTP请求头有哪些”，不是真想让你把RFC里那几十个字段全部背出来，也不是觉得你答得越全越好。你要是真把标准文档从头背到尾，面试官反而会觉得你只是在死记硬背。

他问你这个问题，核心是想确认三件事。

第一，你有没有建立过完整的网络知识框架。请求头不是孤立的知识点，它和HTTP协议版本、TCP连接机制、浏览器行为、服务端处理逻辑都有关联。能说出“Host字段在HTTP/1.1里是必带的，因为一台服务器可以跑多个域名，虚拟主机靠Host来区分”——这句话体现的是你对HTTP协议演进的了解，而不是单纯的记忆力。

第二，你有没有真实操作过。很多候选人能说出二十个请求头名称，但问“Content-Type为multipart/form-data时请求体长什么样”，他就懵了。这说明他压根没抓过包、没看过真实请求。面试官要的是干过活的人，不是背过书的人。

第三，你能不能把一个字段落到实际场景里。比如问“如果从页面A跳转到页面B，服务端怎么知道A传了什么东西”，这就引出Referer和Origin的区别。能答上来的人，工作中遇到防盗链、跨域、CSRF这些问题时才能独立排查。

我用几个典型的追问来感受一下：

• “Accept和Content-Type能一样吗？”
• “请求头Cache-Control: no-cache，是说不缓存吗？”
• “服务端怎么判断请求来自某个特定页面？”
• “多台服务器做负载均衡时，怎么获取用户的真实IP？”
• “Cookies和Authorization都能传身份信息，为什么不统一用其中一个？”

这些问题没有一个需要背答案，全是靠理解堆出来的。所以接下来就别抱着“背列表”的心态往下看了，换成“这个字段设计出来是为了解决什么问题”的视角。

2. 面试高频请求头逐个击破：原理、用途与坑

2.1 Host：HTTP/1.1的必带字段，虚拟主机的地基

Http/1.0的时候，请求行里只有路径，没有主机名。因为早年一台服务器就服务一个网站，通过IP就能定位。但后来一台物理服务器上跑多个网站的需求越来越普遍，要是没有Host头，服务器根本不知道该把请求路由到哪个站点。

HTTP/1.1发布时强制规定请求必须带Host头，这就是很多面试衍生问题的源头：Host字段的缺失会导致400错误，服务器的虚拟主机、反向代理、域名绑定全都依赖这个头。

面试时如果能补一句“Host字段的值是域名加端口号，端口号是80或443时经常会省略，但实际传输时默认端口会被补上”，面试官就会觉得你真的抓包看过。

2.2 Content-Type：请求体格式的说明书

Content-Type可能是面试里被问概率最高的一个头，因为它直接关系到请求体长什么样、服务端怎么解析。

最常见的几个取值：

前两个很多人知道，但要注意区分。表单的application/x-www-form-urlencoded把数据编码成a=1&b=2这种串，比如“name=zhangsan&age=18”，而application/json则直接把结构化的JSON字符串塞进请求体里。两者的解析方式完全不同，服务端如果按错类型解析，轻则拿不到参数，重则直接429或500。

multipart/form-data这个要说一下它的原理：它不是直接把整个文件塞进请求体，而是用边界字符串把请求体分成多段，每段里有自己的Content-Disposition说明字段名和文件名。面试官要是深挖这里，说明他在考察你对HTTP报文结构的真实理解程度。

遇到过一种坑：文件上传接口会因为Content-Type少写一个charset参数，导致后端解析出来的文件名出现中文乱码。所以这个头不能光知道“有这回事”，还得知道它影响的是整个请求体的解码方式。

2.3 Accept / Accept-Encoding / Accept-Language：内容协商三兄弟

这三个头代表客户端的“偏好”，服务端会根据它们决定返回什么格式的数据。

Accept标识客户端能接受哪些MIME类型。服务端同时有JSON和XML两种接口返回格式时，可以根据Accept来决定。比如Accept: application/json表示我只认JSON，服务端就该返回JSON，而不是HTML界面。

Accept-Encoding是压缩算法偏好，gzip、deflate、br这些都算。服务端看到这个头，就可能把响应体压缩后再传输，响应头里会带着Content-Encoding: gzip。这里有个面经题很典型：为什么浏览器里看到接口返回的JSON是乱码，但正常使用接口没问题？其实可能的解释就是响应体被gzip压缩了，而请求没声明Accept-Encoding所以收到了压缩数据。这里把方向反过来说就完了。

Accept-Language标识语言偏好，服务端用来决定返回中文页面还是英文页面。有经验的候选人会主动提一句“这个头在本地化项目中尤其重要，接口返回错误信息时需要根据语言偏好切换文案”。

2.4 Content-Length和Transfer-Encoding：报文边界问题

Content-Length表示请求体的字节长度。服务端读完这么长数据后就知道这个请求结束了，该解析下一个请求了。这个字段在HTTP/1.1保持长连接后变得极其重要——因为连接复用后，请求和请求之间没有天然的边界，全靠Content-Length或Transfer-Encoding来划分。

这个也容易引出面试追问：“HTTP和TCP的关系是什么”以及“粘包问题怎么解决”。虽然真正的粘包发生在TCP层，但应用层如果没遵守Content-Length的规范，同样会出现解析错乱。所以这个头不算难，但它是连接机制和报文边界的关键。

当服务端不确定响应长度时，会用Transfer-Encoding: chunked代替Content-Length，响应体被切成多个块，每块前面标一个十六进制长度值。面试时聊到这里，说明你真的读写过HTTP报文。

2.5 Authorization和Cookie：两个容易混的身份凭证

Authorization头是客户端传给服务端的身份凭证，常用的有Basic和Bearer两种形式。

• Basic就是把用户名密码用Base64编码后拼成Basic base64串，这玩意不安全，因为Base64是可逆的，等于明文传输，现在很少直接用。
• Bearer token是更通用的认证方式，OAuth2.0和JWT都走这个路子，格式类似Authorization: Bearer eyJhbGciOi...

Cookie这个头就不展开了，但得说一个面试高频题：Cookie和Authorization的区别。

Cookie是浏览器自动存储、自动携带的，主要配合Session机制用，服务端生成的Session ID存在Cookie里，每次请求自动带上。Authorization通常需要在代码里手动维护和携带，在请求发送前设置，更适合前后端分离和移动端场景。

如果候选人说“Cookie存在本地，Authorization是请求头里的字段，所以Cookie不安全”，这等于把两个层次搞混了。Cookie确实存在本地，但它传递认证信息的载体同样是请求头（Cookie头），两者只是认证方案不同，不能用人话混淆。

2.6 Referer和Origin：来源信息的两种抓法

Referer表示当前请求是从哪个URL跳转过来的。服务端常常用它做防盗链：图片、视频资源只允许在特定域名页面下加载，如果Referer不对就拒绝返回。

但Referer有个毛病：它会暴露完整URL，包括路径参数，这在隐私和跨域场景下不太友好。所以后来定义了Origin，只标识来源的协议、域名和端口，不带路径。

这两个头的区别是面试官最爱追问的细节：

• Refere是完整路径，Origin只有协议域名端口，不带路径和参数。
• Origin主要用在CORS跨域请求和POST请求中，服务端根据Origin决定要不要允许跨域。
• 有的请求没有Referer（比如地址栏直接输URL），但POST请求通常会有Origin。

更要命的是跨域场景：浏览器发起跨域请求时，会自动带上Origin；而Referer可能在跨站时只保留域名，甚至被设置为空。把这两个头的关系理清，就能回答面试官的CORS追问。

2.7 Cache-Control和条件请求头：浏览器缓存的开关

Cache-Control控制缓存策略，但有个常见的坑：no-cache不是说“不要缓存”，而是说“使用缓存前必须回服务器验证一下是否新鲜”，no-store才是真正不缓存。

进一步展开时，还要提到以下几个字段：

• Cache-Control: max-age=3600表示资源在3600秒内可以直接用缓存，不用回源。
• Cache-Control: no-cache时，请求会带If-None-Match（对应响应的ETag）或If-Modified-Since（对应响应的Last-Modified）去向服务器确认。
• 服务器判断资源没变，就返回304 Not Modified，浏览器继续用本地缓存。

能把这套逻辑讲顺，说明你真做过性能优化或碰到过页面缓存不更新的问题。面试官问“为什么我刚发布的页面，其他人看到的还是旧的”，其实就是在考察你有没有真正理解Cache-Control和版本化部署的关系。

2.8 X-Forwarded-For和X-Real-IP：代理后面的真实IP

客户端直接连服务器时，服务端从TCP连接就能拿到客户端IP。但经过Nginx等反向代理后，服务端看到的是代理服务器的IP，真实IP就丢了。

Nginx转发请求时通常会在请求头里加X-Forwarded-For: 客户端IP, 代理1IP，X-Real-IP: 客户端IP。应用层要拿真实IP就得解析这个头。

这个头也有安全风险：如果客户端直连服务器，自己伪造一个X-Forwarded-For头，服务端可能被欺骗。所以靠谱的做法是：只有在信任的代理层才解析这个头，并且一旦发现第一个值是不可信来源，就不要用。

面试中能提到“X-Forwarded-For取第一个值要谨慎，最好从右边取或由反向代理覆盖”，就直接加分了。

2.9 Connection和其他值得提的头

Connection: keep-alive是HTTP/1.1的默认行为，代表连接复用。如果这个头被设为close，就代表请求完成后关闭TCP连接。现在多数服务器也不建议手动改这个头，因为HTTP/2和HTTP/3已经彻底解决了连接复用问题。

另外还有一些值得提的头：

• User-Agent：标识客户端类型和版本，服务端经常用来做浏览器兼容和设备适配。
• Upgrade-Insecure-Requests：告诉服务端客户端支持HTTPS，可以重定向到HTTPS。
• Sec-Fetch-Site/Sec-Fetch-Mode/Sec-Fetch-Dest：CSP等安全策略里会用到的元数据头。

如果能在面试中主动多讲几个，说明你平时真的注意观察过真实请求头的样子。

3. 千万别只背概念，用这两个办法把请求头看清

面试时说的东西，最好是自己亲眼见过、亲手抓过的。这里分享两个我常用的方法，几行命令就能把请求头看穿。

3.1 curl -v：命令行直接看头

curl是后端开发者最常用的调试命令，-v参数可以显示完整请求和响应头。

curl -v https://example.com/api/user -H "Authorization: Bearer token123"

执行后你能看到类似输出：

> GET /api/user HTTP/1.1 > Host: example.com > User-Agent: curl/8.0.1 > Accept: */* > Authorization: Bearer token123

看到那行以>开头的部分了吗？那些就是请求头。用curl传自定义头用-H，不加就是默认头。想只看真实浏览器发出的头，可以故意带上浏览器的User-Agent模拟。

面试前建议亲手试一次，至少能回答“请求头长什么样”这个问题时有个具体印象。

3.2 浏览器DevTools Network面板

前端和全栈开发者最该熟悉的是浏览器控制台的Network面板。打开开发者工具，切到Network标签，刷新页面，点任意一条请求，在Headers面板里能看到Request Headers。

你看到的不是浏览器发出的所有头，但关键头都在，包括Cookie、User-Agent、Referer等。

更关键的是，很多面试场景的细节都能在这里验证。比如：

• 看同一个域名下的请求，Cookie头是不是都带上了？
• 看跨域请求，Network里的请求条是否带Origin？
• 看静态资源的请求，Cache-Control有没有生效？
• 看POST请求，Content-Type到底是什么？

我以前带过一个新人，他面试前自己把Network面板从头到尾翻了一遍，然后把每个头和页面行为对照了一遍。面试时被问“你怎么知道请求有没有走缓存”，他直接说“看Network里有没有显示from disk cache就行”，面试官当场就给过了。

3.3 自己写个服务把收到的请求头打出来

比看工具更硬核的做法是，自己写一个后端服务把收到的请求头全部打印出来。用Node.js或者Python能实现得很快，我这里放一个Python写法：

from flask import Flask, request app = Flask(__name__) @app.route('/debug', methods=['GET', 'POST']) def debug(): headers = dict(request.headers) return headers if __name__ == '__main__': app.run(port=8080)

启动服务后，浏览器访问localhost:8080/debug，返回的就是浏览器发过来的全部请求头。换成curl再请求一次，对比一下，就能看出普通请求和浏览器请求的头差别有多大。

这个练习的最大价值是让你直观体会：浏览器会自动加很多基础头，比如Connection、Cache-Control、Upgrade-Insecure-Requests等，而你手动用代码发请求时，这些头不一定都有。这就能解释很多调接口时遇到的问题：“为什么浏览器访问正常，代码访问就不对”。

4. 面试这样答，才显得有水平

很多人面试时慌，是因为把面试当成“背诵考试”。其实面试官问一个问题，你答完还有机会补充一句，这句话往往比问题本身更重要。

4.1 回答的正确结构

假如面试官问：“说说HTTP请求头有哪些？”

低分回答是：“有Host、User-Agent、Accept、Content-Type、Authorization……”然后死等下一个问题。

高分的回答是抓一个头往深层讲：“HTTP请求头很多，按用途来分主要有几类。身份认证类有Authorization和Cookie，内容协商类有Accept、Accept-Encoding、Accept-Language，缓存控制类有Cache-Control、If-None-Match，跨域和安全相关的有Origin、Referer。重点说一下我日常工作中接触最多的Content-Type，它标识请求体的格式，比如JSON和表单就不一样，文件上传用的是multipart/form-data，服务端解析方式完全不同。之前我们项目里就踩过坑……”

你看，这个结构不是罗列，而是先给分类，再挑最熟的往深处钻。面试官一旦觉得你有体系，追问起来也是顺着你的话问的，你能答得更稳。

4.2 被追问时的应对思路

面试官喜欢顺着你的回答往下问，这里聊几个常见追问的应对思路。

追问：Content-Type: application/json和application/x-www-form-urlencoded的区别是什么？

回答思路：先说格式，再说服务端解析方式，再补一句实际项目里的选择标准。比如“JSON结构更清晰，嵌套数据方便；表单格式请求体会更小，但只能传扁平键值对。目前接口大多选JSON，但老系统里表单格式很常见”。

追问：Cache-Control: no-cache是不是不缓存？

回答思路：千万别跳坑。明确说no-cache是会缓存的，只是使用前必须回服务器验证，no-store才是真的不缓存，然后可以补一句“如果静态资源想要每次更新都生效，通常不用靠no-cache，而是给文件名加hash”。

追问：Nginx代理后怎么拿到真实用户IP？

回答思路：直接说X-Forwarded-For和X-Real-IP，然后补一句注意事项：不要直接用这个头的第一个值，因为客户端可能伪造，最好在代理层把值覆盖掉，或者从可信代理取。

发挥好的关键在于：不要急着把脑子里所有的东西倒出来，而是挑能讲透的讲透，让面试官觉得你“有想法、有实践”。你要是真能说出一两个踩坑经历，效果远好于背二十个字段。

4.3 面试官可能从请求头牵扯到的大纵深

这个点也很重要。HTTP请求头面试题的一个特征是扩展性极强，面试官可能从你回答的任意一个词开始发散。这里列举常见的大纵深链条：

• 从Host → 虚拟主机 / 反向代理 / 负载均衡
• 从Content-Type → 表单提交 / 文件上传 / TCP报文分段 / 粘包
• 从Authorization → 认证方案演进 / Session与JWT / OAuth2
• 从Cookie → Session机制 / CSRF漏洞与防护 / SameSite
• 从Origin → CORS跨域 / 预检请求 / CSRF / 安全策略
• 从Cache-Control → 强缓存与协商缓存 / ETag与Last-Modified / 版本发布 / 性能优化
• 从User-Agent → 反爬 / 设备识别 / 浏览器兼容
• 从Accept-Encoding → gzip / brotli / Web性能优化

面试时，你在回答第一层时就要有意识地留出值得追问的钩子。比如主动说“Cookie有个属性比较容易被忽略那就是SameSite，它和跨站CSRF关系很大”，基本就是在告诉面试官“你往下问这个，我能讲”。这种引导能力，往往决定一轮面试的走向。

5. 常见坑和实战排查速查表

5.1 面试和工作中常见的几个坑

持续性坑一：把Referer和Origin混为一谈。Referer是完整路径，Origin只有协议+域名+端口；跨域请求一定有Origin但不一定有Referer；CORS判定看Origin，防盗链通常看Referer。

这个坑在工作里怎么体现？做跨域配置时，服务端如果把Origin和Referer规则写得互相矛盾，就会出现浏览器请求正常、但服务端日志里两个值不一致的诡异问题。

持续性坑二：没搞清楚Content-Length和Content-Type的协作关系。Content-Type告诉你怎么解析，Content-Length告诉你解析多长一段数据。两个一起配合才能正确读请求体。

持续性坑三：拿到X-Forwarded-For直接当真实IP用。一旦你在自己的业务系统里这样用，别人就可以伪造来路，轻则统计出错，重则绕过IP限制，安全风险极大。

实战中还遇到过接口在服务器上测试正常，一到浏览器就失败的鬼情况，最后排查发现是浏览器带了Expect: 100-continue头，服务器因为配置问题没正确响应，导致上传大文件卡住。这种问题在面试里说出来，会让人立刻对你印象加分。

5.2 排查问题时的速查表

这张表自己也不用刻意背，工作中多排查几轮自然就记住了。面试时能主动提一个“我们之前线上遇到过这种情况，最后发现是某个请求头的问题”，比回答十个理论问题都有用。

5.3 面试时的灵活应对心得

最后分享一个我个人的体会。

面试官问到HTTP请求头，其实不只是想听知识，更是想听你是怎么学习的。如果你能把请求头和工作中的问题联系起来，说明你平时不只是“写业务代码”，还观察过网络层发生了什么。

我见过很多候选人，算法题做得漂亮，但一说到“你负责的接口响应慢，你会怎么排查”就只会说“加机器”。学过请求头后，你就会知道还可以先看看是不是协商缓存没生效，是不是资源没走CDN，是不是Accept-Encoding压缩没开启，甚至看一眼Content-Length是不是异常偏大。

这些技能都是能在面试中直接转化成竞争力的。面试官想看到的，从来都是一个能解决问题的人，而不是一个记得住RFC条文的背诵机器。

你如果真的花一晚上把每个请求头都用调试工具看一遍，再把它们对应的场景在脑子里过一遍，到面试时你就会发现，这类问题不但不难，反而是你最能拿分、最能引导面试官往你熟悉领域走的机会。

祝面试顺利，把请求头这个问题变成你的加分项，而不是拦路虎。