首先得明白状态码的几个大类：

状态码

响应类别

出现原因

1XX

信息性状态码（Informational）

服务器正在处理请求

2XX

成功状态码（Success）

请求已正常处理完毕

3XX

重定向状态码（Redirection）

需要进行额外操作以完成请求

4XX

客户端错误状态码（Client Error）

客户端原因导致服务器无法处理请求

5XX

服务器错误状态码（Server Error）

服务器原因导致处理请求出错

接下来具体分析详细的状态码：

100：（继续）请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
101：（切换协议）请求者已要求服务器切换协议，服务器已确认并准备切换

200 OK
请求已成功。响应返回的信息取决于请求中使用的方法，例如：在响应中发送GET对应于所请求资源的实体;HEAD对应于所请求资源的实体头字段信息只存在于响应报文首部，因为它不会返回报文实体，只返回报文首部;POST返回实体;
201 Created
请求已完成，并导致创建新资源。新创建的资源可以由响应实体中返回的URI引用，具有Location头字段给出的资源的最特定URI。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果无法立即执行操作，服务器应该响应202（已接受）响应。
202 Accepted
该请求已被接受处理，但处理尚未完成。该请求最终可能会或可能不会被执行，因为在实际处理时可能不允许该请求。没有用于从诸如此类的异步操作重新发送状态代码的工具。
202回复是故意不承诺的。其目的是允许服务器接受对某些其他进程的请求（可能是每天只运行一次的面向批处理的进程），而不要求用户代理与服务器的连接一直持续到进程完成为止。使用此响应返回的实体应该包括请求的当前状态的指示，以及指*向状态监视器的指针或用户可以期望满足请求的某些估计。
204 No Content*
表示请求已成功处理，但是没有内容返回（就应该没有内容返回的状况）
也就是返回的响应报文中没有报文实体（其实是没有报文实体的主体部分）
浏览器向服务器发送请求后收到了204，那么浏览器页面不会发生更新
一般用在只是客户端向服务器发送信息，而服务器不用向客户端返回什么信息的情况
206 Reset Content
表示服务器已经完成了部分GET请求（客户端进行了范围请求）
响应报文中包含Content-Range指定范围的实体内容

301 永久性转移
浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B），旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址
302短暂性转移
临时重定向，表示请求的资源临时搬到了其他位置
表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。
303 See Other
表示请求资源存在另一个URI，应使用GET定向获取请求资源
303功能与302一样，区别只是303明确客户端应该使用GET访问
303 表示请求的资源路径发生改变，使用GET方法请求新url。她与302的功能一样，但是明确指出使用GET方法请求新url（第一次请求返回的location）。

304（未修改）

自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 Googlebot 自从上次抓取后网页没有变更，进而节省带宽和开销。

305（使用代理）

请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。

400 Bad Request
表示请求报文存在语法错误或参数错误，服务器不理解，服务器不应该重复提交这个请求，需要修改请求内容后再次发送。
原因以及解决思路： 1:前端提交数据的字段名称或者是字段类型和后台的实体类不一致，导致无法封装；最常见的可能就是后端使用@RequestBody 接收，先仔细排查一遍，不行的话，使用@RequestParam再逐一看一下是否可以封装进去
2：前端提交的到后台的数据应该是json字符串类型，而前端没有将对象转化为字符串类型；这个比较简单，使用JSON.stringify(param) 转换成json字符串

401 Unauthorized
表示发送的请求需要有HTTP认证信息或者是认证失败了
返回401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部以质询用户信息
浏览器初次接受401时，会弹出认证窗口

403 Forbidden
    返回403状态码就是，拒绝或者禁止访问。但是，服务器虽然拒绝或者禁止访问，但是它已经理解了你的请求。
具体原因有以下多种：
     错误代码：403.1
     HTTP 403.1 禁止访问：禁止可执行访问 Internet 信息服务 原因是执行权限不够，解决的方法是： 打开“管理工具”的“Internet 信息服务”，右键选择“WEB站点属性”的“主目录”选项卡，把“执行许可”的选项从“无”改为“纯脚本”就好了。
     错误代码：403.2
     403.2错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览，或者要显示的 HTML 网页所驻留的目录仅标记为”可执行”或”脚本”权限。
     错误代码：403.3
     403.3错误是由于”写入”访问被禁止而造成的，当试图将文件上载到目录或在目录中修改文件，但该目录不允许”写”访问时就会出现此种错误。
     错误代码：403.4
     403.4错误是由于要求SSL而造成的，您必须在要查看的网页的地址中使用”https”。
     错误代码：403.5
     403.5错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的，如果您的浏览器不支持128位加密算法就会出现这个错误，您可以连接微软网站进行浏览器升级。
     错误代码：403.6
     403.6错误是由于IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的 IP 地址列表，并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。
     错误代码：403.7
     403.7错误是因为要求客户证书，当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层 (SSL) 客户证书时会返回此种错误。
404 Not Found
     表示服务器找不到你请求的资源。
405 Method Not Allowed
      请求行中指定的方法不允许由Request-URI标识的资源。响应必须包含一个Allow标头，其中包含所请求资源的有效方法列表。
413 Request Entity Too Large
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的请求实体。服务器可以关闭连接以防止客户端继续请求。
如果条件是临时的，服务器应该包括一个Retry-After头字段，以指示它是临时的，并且在客户端可以再次尝试之后。
414 Request-URI Too Long
服务器拒绝为请求提供服务，因为Request-URI比服务器愿意解释的长。这种罕见的情况是只可能当客户端已经不正确地将POST请求转换到具有长查询信息的GET请求中，当客户端已陷入URI重定向“黑洞”发生（例如，一个重定向的URI指向前缀它本身的后缀，或者当服务器受到试图利用固定长度缓冲区来读取或操作Request-URI的某些服务器中存在的安全漏洞的客户端的攻击时。
415 Unsupported Media Type
服务器拒绝为请求提供服务，因为请求的实体采用所请求方法的请求资源不支持的格式。

416（请求范围不符合要求）如果页面无法提供请求的范围，则服务器会返回此状态码

428 Precondition Required (要求先决条件)
先决条件是客户端发送 HTTP 请求时，如果想要请求能成功必须满足一些预设的条件。
一个好的例子就是 If-None-Match 头，经常在 GET 请求中使用，如果指定了 If-None-Match ，那么客户端只在响应中的 ETag 改变后才会重新接收回应。
先决条件的另外一个例子就是 If-Match 头，这个一般用在 PUT 请求上用于指示只更新没被改变的资源，这在多个客户端使用 HTTP 服务时用来防止彼此间不会覆盖相同内容。
当服务器端使用 428 Precondition Required 状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务器提供一种有效的方法来阻止 'lost update' 问题。

429 Too Many Requests (太多请求)
当你需要限制客户端请求某个服务数量时，该状态码就很有用，也就是请求速度限制。
在此之前，有一些类似的状态码，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （这不是HTTP定义的状态码）
如果你希望限制客户端对服务的请求数，可使用 429 状态码，同时包含一个 Retry-After 响应头用于告诉客户端多长时间后可以再次请求服务。

431 Request Header Fields Too Large (请求头字段太大)
某些情况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431 Request Header Fields Too Large 来指明该问题。
我不太清楚为什么没有 430 状态码，而是直接从 429 跳到 431，我尝试搜索但没有结果。唯一的猜测是 430 Forbidden 跟 403 Forbidden 太像了，为了避免混淆才这么做的，天知道！

这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错

500 Internal Server Error
表示服务器执行请求的时候出错了，可能是服务器端的bug,但是也可能是前端的问题，比如后台报了序列化错误，可能就是因为你的前端没有设置content-type=application/json

502 Bad Gateway
服务器在充当网关或代理时，在尝试完成请求时从其访问的上游服务器收到无效响应。

503 Bad Gateway
由于服务器的临时过载或维护，服务器当前无法处理请求。这意味着这是一个暂时的条件，经过一段时间的延迟后会得到缓解。如果已知，延迟的长度可以在Retry-After报头中指示。如果没有给出Retry-After，客户端应该像处理500响应一样处理响应。

注意：503状态代码的存在并不意味着a
服务器必须在变得过载时使用它。有些服务器可能希望
简单地拒绝连接。

504（网关超时）服务器作为网关或者代理，但是没有及时从上游服务器收到请求
505（HTTP版本不受支持）服务器不支持请求中所用的HTTP协议版本

511 Network Authentication Required (要求网络认证)
对我来说这个状态码很有趣，如果你在开发一个 HTTP 服务器，你不一定需要处理该状态码，但如果你在编写 HTTP 客户端，那这个状态码就非常重要。
如果你频繁使用笔记本和智能手机，你可能会注意到大量的公用 WIFI 服务要求你必须接受一些协议或者必须登录后才能使用。
这是通过拦截HTTP流量，当用户试图访问网络返回一个重定向和登录，这很讨厌，但是实际情况就是这样的。

使用这些“拦截”客户端，会有一些讨厌的副作用。在 RFC 中有提到这两个的例子：

如果你在登录WIFI前访问某个网站，网络设备将会拦截首个请求，这些设备往往也有自己的网站图标 ‘favicon.ico'。登录后您会发现，有一段时间内你访问的网站图标一直是WIFI登录网站的图标。
如果客户端使用HTTP请求来查找文档（可能是JSON），网络将会响应一个登录页，这样你的客户端就会解析错误并导致客户端运行异常，在现实中这种问题非常常见。
因此 511 状态码的提出就是为了解决这个问题。

如果你正在编写 HTTP 的客户端，你最好还是检查 511 状态码以确认是否需要认证后才能访问。

参考原文：https://blog.csdn.net/pulong0748/article/details/81838086