每年九十月份是前端岗位求职最密集的时段。圈里人管这叫铜九铁十听名字就知道这个阶段岗位数量不少但竞争也最凶。我每年这时候都会帮身边的朋友做模拟面试发现一个规律不管是校招还是社招网络协议这块八股文几乎必考而且很多同学挂就挂在网络题上。倒不是说网络知识有多难而是大家平时写业务代码天天跟fetch、axios打交道但对底层协议的理解停留在会用层面面试官一追问就露馅。这篇内容我打算把前端面试里网络相关的高频考点系统地捋一遍从 DNS、TCP 到 HTTP 协议演进、缓存机制、跨域方案、WebSocket每一块都按面试官想听到什么答案的标准来拆解适合正在准备秋招面试的同学也适合想系统补一下网络基础的初中级前端。1. 为什么网络是前端面试八股文里的硬骨头1.1 前端岗位的面试到底在考察什么很多准备面试的同学有个误区觉得前端面试考网络就是背几个概念。实际上面试官考察网络知识背后有三层意图第一看你有没有完整理解一次 HTTP 请求从输入 URL 到页面渲染的完整链路第二看你遇到页面加载慢、资源加载失败这类实际问题时能不能从网络层面定位原因第三看你对 HTTP 协议演进、缓存、跨域这些机制的理解深度来判断你未来能不能解决复杂的前端性能问题。所以你会发现网络题很少单独出通常是和浏览器渲染、性能优化、工程化配置揉在一起问。比如面试官问页面加载慢怎么排查你可以从 DNS 解析耗时、TCP 连接耗时、TLS 握手耗时、首字节时间TTFB、资源加载瀑布图Waterfall这些网络维度一层层拆这一套答下来面试官基本就能判断你的水平了。1.2 网络知识在面试中的出题方式与高频考点根据我这两年收集的面经数据前端面试中网络相关的问题主要集中在六个方向DNS 解析流程、TCP 三次握手与四次挥手、HTTP 版本演进与核心机制、HTTP 缓存、跨域与 CORS、WebSocket 与 CDN。其中 HTTP 缓存和跨域属于最高频考点几乎每三场面试就有一场会问到DNS 和 TCP 握手属于基础必答项HTTP/2 和 HTTP/3 的对比则是近几年面试官非常爱追问的新方向。这里有个规律值得注意面试官对网络题的追问深度往往和你的简历写的技术栈相关。你写了熟悉 HTTP 协议他就会追问到 HTTPS 握手细节你写了做过前端性能优化他就一定会问缓存策略和 CDN 加速原理。所以准备的时候要有一问到底的意识每个知识点至少要准备两层追问的回答。2. 网络基础协议DNS 与 TCP前端人必须吃透的两块地基2.1 DNS 解析全过程拆解从输入域名到拿到 IPDNSDomain Name System的作用简单说就是把域名翻译成 IP 地址但面试考的是你对整个解析链路有没有完整的认知。当你在浏览器地址栏输入www.example.com并回车DNS 解析大致经历这么几步第一步浏览器先查自己的 DNS 缓存查不到就去查操作系统层面的缓存比如 Windows 的 hosts 文件配置就是优先于系统缓存的系统缓存也没有就发起真实 DNS 查询请求。第二步请求会到达配置的本地 DNS 服务器通常是你网络运营商提供的本地 DNS 服务器先查自己的缓存没有缓存就向根域名服务器发起查询。第三步根域名服务器不会直接告诉你 IP它会返回顶级域名服务器的地址比如.com对应的顶级域名服务器地址本地 DNS 再去问顶级域名服务器顶级域名服务器返回的是权威域名服务器的地址也就是你注册域名时服务商提供的 NS 记录最后本地 DNS 向权威域名服务器发起查询拿到最终的 IP 地址并把结果逐级缓存下来。整个链路里有一个细节面试官特别喜欢考DNS 使用的是 UDP 协议端口是 53因为查询请求很轻量用 UDP 更快。但区域传输域名服务器之间同步数据会用到 TCP这是为了保证数据完整性。另外DNS 解析结果在浏览器层面有缓存时间由响应头里的 TTL 字段控制这就是为什么你修改了 DNS 解析配置后可能要等几分钟甚至更久才能生效因为中间各级缓存还没过期。我在实际开发中踩过这样的坑本地联调时改了 hosts 文件把域名指向本地 IP但浏览器仍然走了真实线上 IP排查了半天发现是浏览器 DNS 缓存没刷新。后来养成了习惯改完 hosts 先打开chrome://net-internals/#dns清一下缓存或者直接用无痕模式调试。这种实战经验面试时顺嘴提一句面试官会觉得你是真有过线上问题处理经验的。2.2 TCP 三次握手与四次挥手连接建立的完整对话TCP 是 HTTP 底层依赖的传输层协议面试必考三次握手和四次挥手。握手本质上是双方确认彼此的收发能力三次挥手建立连接的过程可以这样理解客户端先发一个SYN报文同步序列编号表示我要建立连接这是第一次握手服务端收到后回复SYN ACK表示收到你的请求我也准备好建立了这是第二次握手客户端再回一个ACK表示收到你的确认我们开始传数据吧这是第三次握手。为什么不是两次握手这是面试官必追问的问题。原因在于如果只有两次握手服务端无法确认客户端是否收到了自己的同步请求。假设客户端第一次SYN因为网络延迟重传了服务端收到了两个SYN但只回复一个ACK客户端可能根本没收到这个确认导致服务端白白为一条无效连接分配资源。三次握手的作用就是让双方都能确认对方的接收能力正常避免这种半开连接的资源浪费。四次挥手则是断开连接的过程主动关闭方发送FIN表示我数据发完了被动关闭方回复ACK表示知道了但我可能还有数据要发等被动关闭方数据发完再发FIN表示我也发完了主动关闭方回复最后一个ACK连接才真正关闭。这里有个特殊状态叫TIME_WAIT主动关闭方在发送最后一个ACK后要等待 2MSL报文最大生存时间的两倍才真正关闭目的是确保对方能收到最后的确认否则对方会一直重发FIN。我面试过的一些候选人能把三次握手的报文名字背出来但问他为什么 TCP 连接是可靠传输就答不上来。其实可靠传输的核心在于确认应答机制ACK、超时重传机制、流量控制滑动窗口、拥塞控制慢启动和拥塞避免。这四个机制才是 TCP 面试题的根本握手挥手只是表象。准备的时候建议你把每个机制的触发场景想明白比如什么情况下会触发快速重传答出来就是加分项。2.3 面试官为什么爱在握手细节上连环追问面试官追问握手细节通常是为了测试你对计算机网络的理解是不是停留在背诵层面。比如他会问第三次握手失败了怎么办此时客户端已经进入ESTABLISHED状态但服务端迟迟没收到最后一个ACK服务端会超时重传SYN ACK如果多次重传仍未收到确认服务端就会释放连接资源。这种问题考的是你对协议状态机的理解而不是单纯记结论。再比如他会问为什么挥手要四次握手只要三次因为 TCP 是全双工的断开时两端的数据发送是独立的。握手时双方还没开始传数据SYN和ACK可以合并成一次发送但挥手时被动关闭方可能还有数据没发完不能把FIN和ACK合在一起所以必须拆成四次。我建议你把 TCP 的状态迁移图自己画一遍尤其是TIME_WAIT和CLOSE_WAIT这两个状态的区别这是线上问题排查时经常遇到的状态。实际排查中CLOSE_WAIT堆积往往意味着服务端代码里有连接没正常关闭是资源泄漏的信号TIME_WAIT过多则可能影响新连接的建立速度。这些虽然更多是后端同学关注的问题但前端如果做 Node.js 中间层一样会遇到。面试时能主动讲出这些实际排查经验比单纯背概念加分太多了。3. HTTP 协议演进从 1.0 到 3.0版本对比才是考点核心3.1 HTTP/1.0 与 HTTP/1.1 的关键差异连接复用与缓存头HTTP 协议是前端最应该吃透的一块。目前生产环境大量使用的还是 HTTP/1.1但 HTTP/2.0 的普及率已经很高HTTP/3.0 也在快速落地。面试官最爱的考法是横向对比问 HTTP/1.0 和 HTTP/1.1 有什么区别HTTP/1.1 和 HTTP/2.0 有什么区别为什么要搞 HTTP/3.0。HTTP/1.0 时代的核心问题是每个请求都要新建一次 TCP 连接请求完就断开非常浪费。HTTP/1.1 引入了持久连接Keep-Alive默认支持在一个 TCP 连接上串行传输多个请求这就大大减少了握手开销。同时 HTTP/1.1 还引入了Host头让一台服务器可以挂多个域名虚拟主机这是当年解决 IP 资源紧张的重要举措。但 HTTP/1.1 有个致命伤队头阻塞Head-of-Line Blocking。因为在一个 TCP 连接上请求是串行的前一个请求响应没返回后面的请求就得排队等着。虽然浏览器会为同一个域名开多个 TCP 连接通常是 6 个来缓解这个问题但本质上没解决。这个瓶颈就是 HTTP/2.0 要解决的核心问题。3.2 HTTP/2.0 的多路复用与二进制分帧HTTP/2.0 最大的革命是引入了二进制分帧层把请求和响应拆分成一个个小的帧Frame然后通过流Stream传输。多个请求的帧可以在同一个 TCP 连接上交错传输接收方再根据帧头信息重新组装这就是多路复用Multiplexing。它彻底解决了 HTTP/1.1 的队头阻塞问题——注意这里的队头阻塞指的是应用层的请求阻塞不是 TCP 层的。HTTP/2.0 还有几个重要特性头部压缩HPACK因为请求头里很多字段是重复的Cookie、User-Agent 等通过静态表和动态表压缩可以大幅减少传输体积服务端推送Server Push服务端可以主动把客户端可能需要的资源推过去比如页面 HTML 里引用的 CSS 和 JS以及请求优先级让关键资源优先传输。但 HTTP/2.0 有一个遗留问题它底层的 TCP 连接如果发生丢包TCP 的重传机制会导致所有流都阻塞等待这就是TCP 层队头阻塞。网络质量越差这个问题越明显。这也是 HTTP/3.0 出现的原因——干脆把传输层协议换掉。3.3 HTTP/3.0 的 QUIC 革命为什么基于 UDP 反而更快HTTP/3.0 的核心变化是抛弃 TCP改用基于 UDP 的QUIC 协议。很多人第一反应是UDP 不是不可靠传输吗怎么反而更可靠了关键在于 QUIC 在用户态实现了可靠性机制相当于把 TCP 的可靠传输能力搬到了 UDP 之上同时解决了 TCP 的两个痛点一是握手延迟TCP 加 TLS 需要至少 2 个 RTT往返时间QUIC 的握手可以把传输和加密握手合并做到 0-RTT 或 1-RTT 建立连接二是队头阻塞QUIC 支持多路复用每个流独立交付一个流的丢包不会阻塞其他流。QUIC 还有一个实用特性叫连接迁移Connection Migration因为 TCP 连接是用四元组源 IP、源端口、目标 IP、目标端口标识的你从 WiFi 切到 4GIP 变了TCP 连接就得断开重连。QUIC 用连接 ID 标识连接网络切换后连接依然可以保持这对移动端体验提升非常明显。面试官如果问你HTTP/3.0 为什么快你能从握手 RTT、队头阻塞、连接迁移三个维度回答基本就是满分答案了。这里我说个准备建议面试时不要只背差异点最好能结合你实际项目中的网络环境来讲。比如你做过移动端 H5 优化可以说我们当时把站点切到 HTTP/2 后多资源并行加载性能提升明显但弱网环境下仍然能感受到丢包重传的影响这就把书本知识和实战经验结合起来了。4. 缓存机制与 HTTPS面试必问的两个高频专题4.1 强缓存与协商缓存浏览器缓存的完整工作流程HTTP 缓存是前端面试网络题里的顶流几乎逢面必考。缓存机制分两大类强缓存也叫本地缓存和协商缓存也叫对比缓存。强缓存的意思是浏览器判断本地缓存没过期直接使用缓存资源连请求都不发。协商缓存的意思是缓存可能过期了浏览器带着资源标识发一个请求去问服务器这个资源还能用吗服务器说可以用就返回304 Not Modified浏览器继续用缓存。强缓存靠两个响应头控制Expires和Cache-Control。Expires是 HTTP/1.0 时代的写法指定一个绝对过期时间但它有个问题——服务器时间和客户端时间可能不一致导致缓存判断不准。Cache-Control是 HTTP/1.1 的替代方案最常用的值是max-age3600表示资源在 3600 秒内有效这是相对时间不受时钟偏移影响。两者同时存在时Cache-Control优先级更高这也是面试官爱考的知识点。协商缓存则通过两对请求/响应头实现Last-Modified与If-Modified-Since是一对ETag与If-None-Match是另一对。前者用文件的最后修改时间判断精确到秒如果文件在 1 秒内被修改多次就判断不出来后者用文件内容的哈希标记判断精准度更高。两者同时存在时ETag优先级更高。4.2 缓存判断流程图面试时怎么讲才能拿高分面试官让讲缓存流程时很多同学会背得颠三倒四。我建议你按这个顺序组织答案浏览器发起请求前先检查强缓存是否命中命中就直接用不发请求状态码显示200 (from disk cache)或200 (from memory cache)强缓存没命中就带上协商缓存的标识If-Modified-Since和If-None-Match发请求给服务器服务器根据这些标识判断资源是否变化没变化返回304浏览器继续用缓存变化了返回200和新资源浏览器更新缓存。整个流程一句话总结先强后弱强缓存不发请求协商缓存发请求但可能不传资源。这里有两个容易被忽略的细节。第一Cache-Control的优先级高于Expires同时设置时以Cache-Control为准。第二no-cache和no-store是两个容易混淆的指令no-cache的意思是不要直接用强缓存每次先去服务器协商验证一下它并不禁止缓存no-store才是真正禁止任何形式的缓存。很多同学把no-cache理解成不缓存这在面试里是个明显的扣分点。实际项目里静态资源的缓存策略通常是给文件名加指纹比如app.a1b2c3.js并设置Cache-Control: max-age31536000, immutable因为文件名一变就相当于新资源可以放心缓存一年而index.html这类入口文件设置no-cache保证每次能拿到最新的资源引用列表。这个策略我在项目里反复用过面试时能讲清楚原理和取舍就是很扎实的加分项。4.3 HTTPS 握手过程与中间人攻击从对称加密到非对称加密HTTPS 面试题的套路很固定先问 HTTPS 和 HTTP 的区别再问握手过程再追问为什么用混合加密。HTTPS 的核心就是在 HTTP 和 TCP 之间加了一层 TLS/SSL 协议解决三个问题加密传输防止窃听、身份验证防止冒充、完整性校验防止篡改。TLS 握手大致流程如下客户端发ClientHello携带支持的 TLS 版本、加密套件列表和一个随机数服务器回ServerHello选定加密套件并返回自己的证书和另一个随机数客户端验证证书的合法性是否由可信 CA 签发、域名是否匹配、是否过期验证通过后生成第三个随机数预主密钥用服务器证书里的公钥加密并发送给服务器服务器用私钥解密得到预主密钥双方根据三个随机数各自生成相同的会话密钥之后双方用对称加密的会话密钥通信。为什么不用纯非对称加密因为非对称加密计算开销大不适合传输大量数据所以只用来安全地交换会话密钥后续数据用对称加密如 AES传输这就是混合加密方案。为什么不用纯对称加密因为密钥怎么安全地传给对方是个死结需要非对称加密来解决密钥分发问题。中间人攻击则是面试官最爱的追问如果你的电脑里被安装了恶意根证书或者用户忽略了证书验证警告中间人就可以用自己伪造的证书与客户端建立加密通道客户端浑然不知。这就是为什么浏览器对证书错误提示非常严格——本质上是在防中间人攻击。前端开发中常见的nginx配置证书、HTTPS混合内容警告页面是 HTTPS 但加载了 HTTP 资源都是这个知识点的实战延伸。5. 跨域与 CORS前端网络面试的送命题5.1 同源策略与 CORS 原理为什么会有跨域问题同源策略是浏览器最重要的安全机制之一它规定只有协议、域名、端口三者都相同两个页面才属于同源可以互相访问资源和修改 DOM。不同源的页面之间浏览器会阻止一些请求因为这是防止恶意网站盗取你数据的核心防线。记住核心判断标准协议、域名、端口三者缺一不可http://example.com和https://example.com都算跨域哪怕域名完全一样。前端最常见的跨域场景是页面部署在http://localhost:8080接口在http://api.example.com此时请求就是跨域的。浏览器不会阻止请求发出但会拦截响应——这是理解 CORS 的关键。实际流程是浏览器发出跨域请求服务器正常处理并返回响应但浏览器检查响应头里没有正确的Access-Control-Allow-Origin就把响应拦截了前端收到的就是 CORS 错误。5.2 预检请求与会话场景简单请求和复杂请求的区别跨域请求分两类简单请求和复杂请求分类标准需要记清楚。简单请求要同时满足三个条件请求方法是GET、HEAD、POST之一请求头只能是Accept、Accept-Language、Content-Language、Content-Type等几个安全字段Content-Type只能是application/x-www-form-urlencoded、multipart/form-data、text/plain之一。不满足这些条件的就是复杂请求。复杂请求会触发预检请求Preflight浏览器先发一个OPTIONS请求问服务器我准备发一个带Authorization头的 PUT 请求你允许吗服务器通过Access-Control-Allow-Headers、Access-Control-Allow-Methods来声明允许的请求头和请求方法只有预检通过浏览器才会发真正的请求。这里有个实际开发中常踩的坑很多后端同学只配了Access-Control-Allow-Origin没配Access-Control-Allow-Headers导致前端带了自定义请求头就报跨域错误。排查这类问题时打开 DevTools 的 Network 面板看有没有OPTIONS请求、响应头里有没有对应的Access-Control-*字段定位非常快。跨域解决方案这块面试官通常期待你答出 CORS、JSONP、反向代理、postMessage 四种方案。JSONP 的原理是利用script标签不受同源策略限制的特性通过动态插入 script 标签加载接口返回的 JS 代码但只能支持 GET 请求现在已经被 CORS 逐渐替代。反向代理是开发环境最常用的方案原理就是通过同源的服务器中转请求webpack-dev-server的proxy配置和nginx的反向代理都是这个思路绕开了浏览器的同源限制。postMessage则主要用于iframe场景下的跨窗口通信。每种方案的优缺点、适用场景要能讲清楚这是面试官判断你工程经验的重要依据。6. WebSocket、CDN 与其他高频网络考点6.1 WebSocket 连接机制与心跳保活WebSocket 是前端实现实时通信的首选方案面试考察点集中在三个方面连接原理、与 HTTP 的关系、以及心跳机制。WebSocket 的连接建立流程是先通过 HTTP 发起升级请求请求头里带Connection: Upgrade和Upgrade: websocket服务器返回101 Switching Protocols状态码协议就从 HTTP 切换成了 WebSocket之后双方就可以在一个全双工通道上进行低延迟的实时通信。与 HTTP 的区别是重点HTTP 是半双工、请求-响应模式只能客户端主动发起WebSocket 是全双工服务端可以主动推送消息而且连接建立后没有 HTTP 请求头那些冗余开销适合聊天、实时行情、在线协作这类场景。我在做实时数据看板项目时最初用的是轮询每 5 秒请求一次接口能跑但浪费资源换成 WebSocket 后服务器一有数据变更就推给前端用户体验和资源消耗都好了很多。心跳机制是 WebSocket 面试里爱追问的实战细节。因为 TCP 连接可能因为网络问题处于假死状态双方都不知道连接已断。解决方案是客户端定时发送 ping 帧或自定义心跳消息服务器收到后回复 pong如果客户端连续多次没收到 pong就判定连接断了主动重连。前端实现时可以写一个简单的定时器逻辑function startHeartbeat(ws, interval 30000) { let heartbeatTimer null; let lostCount 0; const MAX_LOST 3; function sendPing() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping })); } } ws.addEventListener(open, () { heartbeatTimer setInterval(() { lostCount 1; if (lostCount MAX_LOST) { console.warn(heartbeat lost, reconnect...); clearInterval(heartbeatTimer); reconnect(); return; } sendPing(); }, interval); }); ws.addEventListener(message, (event) { const data JSON.parse(event.data); if (data.type pong) { lostCount 0; } }); }这个代码里的关键是lostCount的累计机制超时未收到 pong 就累计连续超过阈值才断开重连避免网络抖动导致频繁重连。6.2 CDN 加速原理与前端性能的关联CDN内容分发网络面试题通常不会单独考而是糅合在如何做前端性能优化里。CDN 的原理简单说就是在全球各地部署边缘节点把静态资源缓存到离用户最近的节点上用户请求资源时DNS 解析会把域名解析到最近的节点 IP避免所有用户都回源站请求从而大幅降低网络延迟。整个流程是用户访问cdn.example.com/static/app.jsDNS 解析时 CDN 服务商会根据用户的 IP 地理位置返回最近的边缘节点 IP边缘节点收到请求后如果本地有缓存就直接返回没有缓存就回源站拉取资源并缓存到本地供后续请求使用。这里有个概念叫回源回源的频率直接影响源站压力和用户体验。前端面试中CDN 相关的追问方向通常是为什么静态资源要放 CDN 而不是放业务服务器答案从成本和性能两个维度说静态资源访问量大如果都从业务服务器出既占带宽又拖慢动态接口的响应速度放到 CDN 后边缘节点分流了绝大多数静态请求源站专注处理动态逻辑。另外 CDN 资源一定要配合指纹命名因为 CDN 节点缓存更新有延迟如果你覆盖同名文件用户拿到的可能是旧缓存指纹命名能保证新资源被正确拉取。6.3 弱网环境与前端网络状态监测随着移动端 H5 场景增多面试官开始关注弱网适配问题。前端可以通过navigator.connectionAPI 获取网络信息比如effectiveType网络类型slow-2g、2g、3g、4g、downlink估算下行带宽、rtt估算往返时间。利用这些信息可以动态调整页面加载策略比如弱网下先加载核心文本内容、降低图片质量、推迟非关键资源的加载。还有一个实用的 API 是navigator.onLine和online/offline事件用来监听网络断网与恢复。我在做离线优先的 H5 应用时就用这个事件来提示用户当前网络不可用并在网络恢复后自动同步本地缓存的表单数据。实现思路是监听offline事件时把用户提交的数据存入 localStorage监听online事件时把积压的数据批量发到服务器。这个方案虽然简单但在网络不稳定的业务场景里非常实用面试里讲出来也很加分。开发者工具里的 Network 面板提供了非常完整的网络性能分析能力包括每个请求的 DNS 解析耗时、连接耗时、TLS 握手耗时、TTFB、内容下载耗时。你可以在 DevTools 里调低网络速度到Slow 3G观察页面加载的水瀑布图Waterfall找出瓶颈请求然后针对性地优化。面试官问页面加载慢怎么排查你如果能说出这套工具链和排查思路比单纯背概念强太多了。7. 常见问题与面试追问实录专门整理的避坑清单7.1 高频追问 Top 5从背结论到讲原理我把这两年高频出现的网络面试追问整理成一张速查表你可以对着自测追问问题期望答案常见翻车点为什么 HTTP/1.1 还会有队头阻塞一个 TCP 连接上请求只能串行前一个响应没返回后续就得等说成 TCP 层丢包重传导致的队头阻塞混淆了层次Cache-Control: no-cache是不缓存吗不是是每次都要到服务器校验no-store才是禁止缓存分不清 no-cache 与 no-storeETag 和 Last-Modified 谁优先ETag 优先因为 ETag 能精确判断内容变化说 Last-Modified 更准确正好反了预检请求会带 Cookie 吗预检 OPTIONS 请求一般不带业务数据Cookie 在正式请求里带以为预检请求也带完整的业务 Cookie四次挥手为什么不能合并成三次被动关闭方可能还有数据要发无法把 FIN 和 ACK 同时发出说不出全双工的本质原因这里我特别说一下no-cache这个问题我面试过不下十个人至少一半会答错。大家更容易理解缓存的字面意思但no-cache的真实含义是使用缓存前必须验证它允许缓存存储但每次使用前要到服务器确认资源没过期。你把它理解成强制协商缓存就对了。7.2 面试中容易翻车的细节坑真实案例复盘有个真实案例让我印象很深一个候选人基本功很扎实但讲到 HTTPS 时说了句证书的作用是给数据加密这句话一出口面试官立刻追问那公钥加密和私钥加密分别做什么用候选人支支吾吾答不上来。证书的本质是身份凭证它绑定了域名和公钥由 CA 签名保证公钥确实属于这个域名而数据加密是握手后通过会话密钥完成的。这两个概念不能混。另一个常见翻车细节是状态码。面试官问204 和 304 有什么区别很多同学直接懵了。204 No Content 表示请求成功但响应体为空常用于删除操作后返回304 Not Modified 表示资源未修改是协商缓存命中的响应响应体同样为空。两者都不返回内容但含义完全不同。404 和 410 也容易混404 是资源不存在410 是资源曾经存在但被永久删除现在已经不再提供。最后再提醒一个容易被忽略的点HTTP状态码的分类要记牢1xx是信息性响应101 切换协议最常考、2xx是成功200、201、204、3xx是重定向301 永久、302 临时、304 未修改、4xx是客户端错误400、401、403、404、5xx是服务端错误500、502、503、504。每次答状态码的时候顺便补充一下这个状态码在什么业务场景下会出现面试官会觉得你有真实项目经验。7.3 准备网络八股文的最后建议我个人带人准备面试的习惯是三步走第一步是构建完整链路把输入 URL 到页面展示整条链路上涉及的网络知识点串成一条线——DNS、TCP、TLS、HTTP 请求、缓存、渲染每一个环节都要能讲五分钟以上第二步是横向对比把 HTTP/1.1、HTTP/2.0、HTTP/3.0 的差异做成表格把强缓存和协商缓存的判别条件刻在脑子里第三步是实战复盘把你平时开发中遇到的实际网络问题整理成案例比如跨域报错怎么排查、静态资源缓存失效怎么处理、页面加载慢从哪个 Waterfall 指标开始看。网络这块八股文和其他前端知识不太一样它抽象但逻辑性极强一旦把原理想通了就不容易忘。你花了三个晚上把这些协议细节吃透换来的不仅是面试时的顺畅回答更是将来线上问题排查时能快速定位问题源头的底气。说白了面试不只是为了拿 offer这些基础早晚会在你做性能优化、排查线上问题、设计前端架构时派上用场。希望这份梳理能帮你在铜九铁十里少踩几个坑。