chrome F12 里的 400 报错怎么能拦截到

浏览器行为，跟你处不处理没有关系
另外这有啥不好看的，用户不会看，开发看不到了不方便查问题

http status 400 就应该是红色吧

「 F12 里面还是有红色的，不好看」

请原谅我笑了

看看 try catch 能否 handle

现代后端不是都请求返回 200 ，然后 400 、500 状态码 code ，错误说明 msg ，单独存在返回值里吗。单返回个 400 谁懂什么错

这就真是谜之操作了

不是故意抬 1L 的杠，我们还真遇到过这种情况。
给国企内部部署的服务，反馈中有客户截图 devtools console 界面，说有红色的报错让我们处理。
最后领导说不用管。

@persona5 为啥不用管？

重写 console.err 试试，应该可以去掉。

@wangtian2020 后端是 DRF 返回的
```
{data: {…}, status: 400, statusText: 'Bad Request', headers: {…}, config: {…}, …}
config: {transitional: {…}, transformRequest: Array(1), transformResponse: Array(1), timeout: 0, adapter: , …}
data:
content: Array(1)
0: "This field may not be blank."
length: 1
```
虽然是按 restful 接口写的，但是的确是不好处理，比方说这个错误原因，就不好取出来。

@rekulas 异步的好像 try catch 不住

觉得不好看的话，给线上禁用开发者工具
报错日志通过 Sentry 收集

部一个 nginx 处理，报产出 /doge

@persona5 为啥不管呢，前端有业务逻辑可以接受报错的情况？

那是 http 的状态码。不想爆红很简单。后端无脑返回 200 。前端在返回体中自己根据业务 code 判断正常还是错误

可能如上面所说浏览器默认行为不好 handle ，只能像楼上说的 code 放 body 里判断

或者直接无脑请求完毕 console.clear()。。。

这个问题要结合 后端返回 code 是在 body 还是 http 状态码，在引用一张图片(状态码 200 body 里面 404 的痛苦面具)

自定义错误码，后端全部返回 200

直接反调试，打开 F12 就崩溃

在 HTTP 标准中，400 代表服务端无法理解客户端的请求，按标准来说，所有业务当场景中，这一定是不应该出现的，正式客户端的任何请求都应该是在预期范围中的，有错误也应该是业务上预期存在的可能性，即业务上预期的错误应该返回 2xx 状态码，并在返回载荷中说明是什么错误。

除非项目自己将 HTTP 状态码进行了重新定义，比如像 REST 风格中，将状态码和业务捆绑到一起，此时 400 不光代表 HTTP 协议上的错误，也同时代表业务上预期存在的错误。

所以看你们使用状态码是遵循 HTTP 的标准定义，还是有一套自定义；如果是标准定义，那么返回 400 就不是好不好看的问题，而是程序确实存在问题；如果有自己一套定义，就得看当前情况下返回 400 是否合理，合理的话就没必要处理。

另一方面，浏览器通常是严格遵循 HTTP 标准的来设计的，也默认网站开发者是遵循 HTTP 标准来设计网站的，那么不管你们项目如何自定义状态码，浏览器一定认为 400 是个问题，所以会在开发者工具中给予提示。

就好比是消防传感器（感烟）会对室内吸烟行为有反应，吸烟的人知道现在没发生火灾，但消防标准规定传感器就应该在探测到任何烟雾的情况下通知报警。

浏览器的行为是浏览器开发者在代码里定义死的，除非你获得浏览器代码自己魔改，并给用户提供魔改版的浏览器安装包，否则是没法改变浏览器的行为的。
开发者工具是提供给浏览器用户的工具，而不是提供给网站开发者的工具（虽然有时候两者是同一个人），网页上的代码无权控制开发者工具的行为。

我在项目中就加了个环境变量 HTTP_RESPONSE_ALWAYS_RETURN_200 ，如果为 1 ，就所有 response 都返回 200 ，业务响应 code 的前三位还是是对应 HTTP CODE 的。

@libook 嗯，restful 不是太灵活，一般还是按楼上说的，统一 post ，统一返回 200 ，然后在返回包里面自定义状态码，比较可控一点。

不把异常当异常的人，和用 HTTP status 永远 200 的人，原来是同一波人！