为什么那么多公司做前后端分离项目后端响应的 HTTP 状态一律 200？ 第1页

用于分离外网错误还是内网错误

如果一律返回200，却收到了非200的结果，就说明外网出问题了，可能是运营商缓存服务器的问题，可能是DNS污染等等

而内网错误则在200返回的内容里用code来表示，就可以很好的定位问题

很多人开发的时候因为都在内网测试，没有遭遇过外网错误，所以就会觉得这种做法很多余

但在实际使用中，尤其是服务器和用户跨国甚至跨洲的情况下，整个外网传输过程并不稳定，可能会出现各种异常，这种情况下这种一律返回200来区分外网错误和内网错误的做法就显得非常有价值了

举个例子吧，众所周知vercel免费版不大稳定，有时候会503。如果我把自己内部代码错误也http返回503，那么client侧就无法辨别到底是我的代码出问题了还是vercel炸了。如果我用http返回200，code503的办法，client得到了http503那就可以提示用户是vercel炸了而不是我代码出错了，code503才是vercel没炸而我代码炸了。这种思路在白嫖很多免费而不稳定的云服务时非常有用，尤其是如果同时部署了vercer，glitch，heroku等多个平台，可以通过http code判断平台是否爆炸而自动冗余切换其他平台继续服务，对于吾等没钱买pro套餐的用户来说非常好使

根本的原因是：HTTP协议本来就不是设计为业务系统的传输层。

在HTTP协议设计之初，它是用于（基于请求/应答对的web）业务的，后面略微扩展为简单的文件传输（毕竟web也是文件）。所以，HTTP的code本来是应对web页面的业务状态的，是业务的状态码。

但是在restful的各种场景下，HTTP被当作传输层，而上面真正运行的业务却五花八门，完全脱离了web的范畴。所以，HTTP的那套code完全套不上，或者说硬套上去也很别扭：例如说404，找不到页面。当然，你可以宽泛的解释为“找不到资源”——但如果你一个业务请求中涉及到了ABC三个资源，你光一个404，怎么表示到底找不到哪个？如果你说把ABC三个资源合并为一个“虚拟资源”，那么ABC三者到底是“和”关系还是“或”关系？当然，你非要写一份完整的协议文档，详细的解释清楚你的所有的code的套用方式，也不是不行。但就算如此，如果我需要精确知道具体是ABC的哪个（例如说给用户精确的提示），不还是要在payload里折腾一番？那你看绕了一圈，不还是回来了？何必呢？

总之，既然当了传输层，就要有当传输层的自觉：作为业务系统的小配角，不要总想着和主角（应用层）抢戏。

你看看老资格的传输层，返回码（状态码）都是什么？如果是流式传输，那就是字节数。如果是包式传输，要么是包个数，要么就是简单的true/false。

而现在HTTP当作传输层了，那么它本质上是一种高级（变长、可确认、可校验）的UDP。因此，它的code只有200和非200（本质上就是true/false），就理所当然了。