当前位置：首页 > news >正文

304 引发的 SEO 难题：缓存策略与内容更新如何两全？

news 2025/8/10 5:27:10

前端面试：HTTP协议，你真的懂了吗？

在前端开发的世界里，HTTP 协议就像一条看不见的 “高速公路”，连接着客户端与服务器，支撑着无数网页的交互与数据流转。而对于每一位想要在前端领域深耕、从容应对面试挑战的开发者来说，吃透 HTTP 协议的那些 “门道”—— 从最基础的请求方法到关键的状态码，从请求头的奥秘到缓存机制的精髓 —— 都是绕不开的必修课。

今天，我们就来一场 HTTP 协议的 “探秘之旅”，把那些面试中高频出现的知识点掰开揉碎，用最生动的例子、最易懂的语言，带你搞懂 GET 与 POST 的 “爱恨情仇”，分清 PUT 和 PATCH 的 “更新姿势”，解密请求头与响应头的 “隐藏信息”，更要揭开 304 状态码在性能优化中的 “神秘面纱”。准备好了吗？让我们一起出发！

1. 搞懂GET和POST，面试官再也唬不住你！✨

在HTTP协议的江湖里，GET和POST就像一对“欢喜冤家”，总是被拿来比较。它们俩都是向服务器“提要求”的方式，但骨子里却有着天壤之别。搞懂它们，你就拿到了前端面试的“通关秘籍”！

1.1 GET和POST的异同点

想象一下，你和朋友去餐厅吃饭。GET就像是你在菜单上“点菜”，你点的菜品（参数）都清清楚楚地写在菜单上（URL），服务员（服务器）一看就知道你要什么。而POST呢，更像是你给厨师（服务器）递了一张“小纸条”（请求体），上面写着你对菜品（数据）的特殊要求，比如“多放辣”、“少放盐”之类的，这些要求只有厨师才能看到。

在这里插入图片描述

GET请求：

应用场景： 就像你“点菜”一样，主要用于获取资源，对服务器的数据不会产生任何影响。比如浏览网页、查询数据等。
参数传递： 参数会放在URL中，以?连接，多个参数用&连接。比如：www.example.com/search?name=test&age=18。

POST请求：

应用场景： 就像你给厨师递“小纸条”一样，主要用于向服务器提交数据，可能会对服务器资源产生影响。比如注册用户、提交表单、上传文件等。
参数传递： 参数放在请求体（Request Body）中，用户不可见。

1.2 缓存、安全性、请求长度、参数类型大揭秘

除了上面说的，GET和POST还有一些“小秘密”，面试官最喜欢从这些地方下手！

缓存：

GET： 浏览器一般会对GET请求进行缓存。想象一下，你点过的菜，餐厅会记住你的喜好，下次你再点同样的菜，可能直接给你上，不用再问厨师了。这能大大提高访问速度。
POST： 很少或不缓存。因为POST请求通常涉及数据的修改，每次都得“新鲜出炉”，不能用旧的。

安全性：

GET： 参数直接暴露在URL中，安全性较低。就像你把银行卡密码写在纸条上，然后大声念出来，谁都能听到。所以，敏感信息千万别用GET！
POST： 参数在请求体中，相对安全。就像你把银行卡密码写在加密的信封里，只有收件人才能打开。

请求长度：

GET： 由于URL长度的限制，GET请求能发送的数据量有限。就像你点菜的菜单，格子就那么大，写不下太多字。
POST： 请求体没有长度限制，可以发送大量数据。就像你给厨师的“小纸条”，想写多少写多少。

参数类型：

GET： 只能支持ASCII字符，参数类型比较单一。
POST： 支持多种参数类型，比如文本、二进制文件等。就像厨师的“小纸条”上，不仅能写字，还能画图，甚至可以贴个小样。

为了让大家更直观地理解，我们来看一张图：

在这里插入图片描述

这张图清晰地展示了GET和POST请求在客户端和服务器之间的数据流向。GET请求的参数在URL中，而POST请求的参数在请求体中。

// GET请求示例
fetch('/api/users?id=123&name=Alice').then(response => response.json()).then(data => console.log(data));// POST请求示例
fetch('/api/users', {method: 'POST',headers: {'Content-Type': 'application/json'},body: JSON.stringify({ id: 123, name: 'Alice' })
}).then(response => response.json()).then(data => console.log(data));

从代码中可以看出，GET请求的参数直接拼接在URL后面，而POST请求的参数则通过body发送，并且需要设置Content-Type来告诉服务器请求体的数据类型。

2. PUT和PATCH：更新数据，姿势要对！🔄

说完了GET和POST这对“老搭档”，我们再来看看另外两个HTTP方法：PUT和PATCH。它们都用于更新数据，但更新的“姿势”却大不相同。理解它们，能让你在设计API时更加得心应手。

2.1 PUT：更新整个资源

PUT请求就像是“替换”操作。如果你想更新一个资源，PUT会要求你提供这个资源的完整新版本。如果这个资源不存在，PUT还会帮你创建一个新的。

举个例子，你有一张个人简历，上面写着你的姓名、年龄、学历、工作经历等等。如果你用PUT来更新简历，你需要把所有信息（包括没变的）都重新提交一遍。如果服务器上没有你的简历，它就会帮你新建一份。

特点：

幂等性： 多次提交同一个PUT请求，结果都是一样的。就像你替换一份简历，无论替换多少次，最终的简历内容都是你最后提交的那一份。
原子性： 要么全部成功，要么全部失败。不能只更新一部分。

2.2 PATCH：局部更新资源

PATCH请求则更像是“打补丁”操作。它允许你只提交需要修改的部分，而不是整个资源。这在某些场景下能大大提高效率。

还是拿简历举例，如果你只是想更新一下你的联系方式，用PATCH就非常方便了。你只需要提交联系方式这一项，服务器就会帮你把简历上对应的部分更新掉，而其他信息保持不变。

特点：

非幂等性： 多次提交同一个PATCH请求，结果可能不同。因为每次PATCH都可能基于资源的不同状态进行修改。
局部性： 只更新资源的一部分。

在实际开发中，选择PUT还是PATCH，取决于你的业务需求。如果每次更新都需要提供完整的资源，或者资源比较小，PUT是个不错的选择。如果资源很大，或者只需要修改其中一小部分，PATCH就能发挥它的优势了。

3. 常见HTTP请求头和响应头，知己知彼百战不殆！⚠️

HTTP请求头和响应头就像是HTTP通信的“身份证”和“回执单”，里面包含了大量关于请求和响应的元数据。理解这些头部信息，能让你更好地调试网络问题，优化前端性能。

3.1 请求头（Request Headers）

请求头是客户端发送给服务器的信息，告诉服务器它想要什么，以及它能接受什么。常见的请求头有：

Accept： 浏览器能够处理的内容类型。比如text/html、application/json等。这就像你告诉餐厅，你喜欢吃中餐还是西餐。
Accept-Charset： 浏览器能够显示的字符集。比如UTF-8。
Accept-Encoding： 浏览器能够处理的压缩编码。比如gzip、deflate。这就像你告诉餐厅，你喜欢吃辣的还是不辣的。
Accept-Language： 浏览器能够接受的语言。比如zh-CN（简体中文）。这就像你告诉餐厅，你喜欢用中文菜单还是英文菜单。
Connection： 浏览器与服务器之间连接的类型。keep-alive表示保持连接，可以复用TCP连接，提高效率。
Cookie： 当前页面设置的任何Cookie。这就像你的“会员卡”，每次去餐厅都会出示，餐厅就知道你是老顾客了。
Host： 发出请求的域名。这就像你告诉餐厅，你是从哪个分店来的。
Referer： 发出请求的源页面URL。这就像你告诉餐厅，你是从哪个广告或者哪个朋友那里知道这家餐厅的。
User-Agent： 浏览器的用户代理字符串。这就像你告诉餐厅，你是开什么车来的，或者你是步行来的，让餐厅知道你的“身份”。

3.2 响应头（Response Headers）

响应头是服务器发送给客户端的信息，告诉客户端请求的处理结果，以及如何处理响应内容。常见的响应头有：

Date： 表示消息发送的时间。这就像餐厅给你的“小票”，上面有打印时间。
Server： 服务器名称。这就像餐厅的名字。
Cache-Control： 控制HTTP缓存。这是个非常重要的头部，我们后面会详细讲到。
Content-Type： 表示后面的文档属于什么MIME类型。比如text/html、application/json、image/jpeg等。这就像餐厅告诉你，你点的菜是主食还是甜点。

常见的Content-Type值有以下四种：

application/x-www-form-urlencoded： 浏览器的原生form表单，如果不设置enctype属性，那么最终就会以这种方式编码。数据会编码成key1=val1&key2=val2的形式，key和val都会进行URL转码。
multipart/form-data： 这种方式也是一个常见的POST提交方式，通常用于上传文件。比如你上传一张照片到朋友圈，就是用这种方式。
application/json： 服务器端最常使用的JSON字符串格式。现在前后端分离的项目中，大部分数据交互都使用JSON格式。
text/xml： 这种方式主要用来提交XML格式的数据。现在用得比较少了。

4. HTTP状态码304：别小看它，性能优化全靠它！🔧

HTTP状态码304，全称Not Modified，中文意思是“未修改”。它在HTTP缓存机制中扮演着非常重要的角色。别看它只是一个简单的数字，它可是前端性能优化的“幕后英雄”！

4.1 304状态码的含义和作用

想象一下，你第一次去图书馆借了一本书（资源）。图书馆给你盖了个章，上面写着“借阅日期：2025年8月6日”（缓存信息）。下次你再去图书馆，想借同一本书，你把书拿给管理员看，管理员发现书上的章还是“2025年8月6日”，而且图书馆里这本书的版本也没有更新，他就会告诉你：“这本书你已经借过了，而且没有更新，不用再借了！”（返回304状态码），你就可以直接拿走你之前借的那本书了。

在HTTP协议中，当客户端请求一个资源时，如果这个资源在客户端有缓存，客户端会带上一些缓存相关的请求头（比如If-Modified-Since或If-None-Match）去询问服务器。服务器收到请求后，会判断这个资源是否在客户端缓存之后被修改过。如果没有修改，服务器就会返回304状态码，告诉客户端可以直接使用本地缓存的资源，而不需要重新下载。这样就大大节省了网络带宽和服务器资源，提高了访问速度。

304状态码的优点：