HTTP 状态码

完整可以看 MDN： 状态码

状态码类别

1. 1xx：信息性状态码，接收的请求正在处理

   • 100，这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它，服务器必须在请求完成后向客户端发送一个最终响应
   • 101：Switching Protocols，在升级 Websocket 的时候，如果服务端同意变更协议，就会返回这个状态码

2. 2xx：成功请求，请求正常处理完毕

   • 200：OK 表示从客户端发的请求服务端正确处理了
   • 201: Created 请求成功并且服务器创建了新的资源，这通常是在 POST 请求，或是某些 PUT 请求之后返回的响应。
   • 204：No content 服务器成功处理了请求，但是没有返回任何内容
   • 205：reset content 请求成功 并且要求客户端重置视图
   • 206 partial content 进行范围请求，使用 Range 字段的时候，会返回这个状态码进行响应

3. 3xx 重定向

   • 301: 永久性重定向 请求的资源已经永久移动到新的位置，搜索引擎会记录 301 的 location 指向的地址
   • 302：临时性重定向 表示请求的资源已经临时移动到新的位置，未登录的用户重定向到登录页面，登录成功后，再重定向到之前的页面
   • 303: 重定向 资源存在另一个URL 应该用get方法获取资源(一般用于上传文件后，返回的重定向到消息确认页面或者上传进度页面)
   • 304: not modified 客户端可以通过本地缓存来更新，所请求的资源未修改。
   • 307: 临时重定向 但是与 303 不同的是期望客户端保持请求方法不变向新的地址发出请求
     • （一般浏览器会自动由 post -> get 但是307不会 还是 post -> post）

4. 4xx 客户端错误

   • 400 bad request 请求报文语法错误或格式不对
   • 401 unauthorized 表示请求需要身份验证
   • 403 forbidden 请求资源被服务器拒绝
   • 404 not found 在服务器未找到请求的资源
   • 405 method not allow 服务器禁止使用这种方法

5. 5xx 服务器错误

   • 500: internal server error 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理
   • 501: not implemented 服务器不支持当前请求所需要的某个功能
   • 502: bad gateway （错误网关）服务器作为网关或代理，从上游服务器收到无效响应
   • 503: service unavailable 服务器暂时在超负载或停机维护(nginx限速)
   • 504: gateway timeout 网关或代理服务器无法在规定时间获得响应(代码执行时间超过 或 死循环)

同样是重定向 302 303 307有什么区别

302 是 http1.0 的协议状态码，在 HTTP1.1 后为了细化 302，又分出了 303 和 307

这三个状态码都是临时重定向，但是有一些区别

303 重定向是对 POST 请求的安全处理，客户端使用 POST 来请求资源时，如果资源需要进行重定向，则服务端需要返回一个 303 状态码，告诉客户端使用 GET 来获取资源，以避免数据安全的问题

303 和 307 的区别在于 303 期望客户端使用 GET 方法来获取资源，而 307 期望客户端保持原有的请求方法

浏览器会缓存 301 页面吗？如何清除缓存？

假设不小心将初始页面永久重定向到 301 页面，想要临时重定向到 302 页面。

会发现 浏览器会缓存 301 页面，即使是临时重定向到 302 页面，浏览器也会缓存 301 页面。

• 控制台禁用缓存
• 清楚历史记录
• Network -> Disable Cache
• 强刷浏览器

或者可以在服务端设置 Cache-Control: no-cache

介绍一下 304 的过程

浏览器请求资源时，首先命中资源的 Expires 和 Cache-Control，Expires 过期时间受限于本地时间，如果修改了本地时间，可能会导致缓存失败，可以通过 Cache-Control: max-age= 来指定最大的生命周期时间，状态返回 200，但不会请求数据，在浏览器中能看到 from cache 的字段

如果强缓存失效，会进入协商缓存阶段，首先验证 Etag 可以保证每一个资源是唯一的，资源变化都会导致 ETag 变化。服务端根据客户端发送的 If-None-Match 来判断是否命中缓存

到了协商缓存 Last-Modified 阶段，客户端第一次请求资源时，服务端返回的 header 中会加上 Last-Modified，Last-Modified 是一个时间标识该资源的最后修改时间，再次请求该资源的时候，请求头会添加 If-Modified-Since，值为之前缓存的值，服务端根据这个时间来判断是否和资源的最后修改时间命中，来决定是否命中缓存。

并不是绝对的，要根据实际场景来看，在一些场景下，为了避免被客户端缓存，服务器需要返回 200 响应状态码来确保客户端拿到的是最新的数据， 304 状态码就不适用了；在另一些场景下，需要加速加载速度，减少网络带宽消耗，就可以使用 304 状态码来避免重复加载资源。 对于一些静态资源，例如图片、CSS、JS 文件等，由于很少更改，因此适合使用 304 状态码缓存，这可以减少带宽消耗，更快地加载资源，提升网站的性能和用户体验。

但是搜索引擎更青睐更新频率高的网站，通过特定的时间对网站抓取返回的状态码来调节网站抓去频次，如果一直是 304，抓取次数就会降低，相反，如果更新快，回访的率就会高。

但如果返回 200，即使网页内容未发生变化，搜索引擎仍然会重新抓取并索引网页。同时被爬虫的次数的增多也会给服务器造成压力。但也有助于优化搜索引擎的爬虫抓取。

当搜索引擎的爬虫请求某个网页时，如果该网页没有被修改，服务器会返回 304 状态码，爬虫就会直接从缓存中读取该页面，而不会重新抓取和索引。这可以降低服务器的负担，减少搜索引擎爬虫的抓取频率，有助于优化搜索引擎爬虫的抓取结果和网站的排名。