状态码 200 的 Axios POST 请求掉进 catch 块，这个坑我帮你们踩过了

有段时间线上日志里冒出一类很诡异的现象：Axios 发 POST 请求，Network 面板里状态码明晃晃写着 200，响应内容也在，但代码却进了 catch 块，then 那边毫无动静。刚开始以为是偶发的网络抖动，后来发现能稳定复现，就顺着调用链查下去，发现原因不止一种，有的藏得还挺深。

排查下来，常见的情况大概有这几类。

第一个容易忽略的地方是响应拦截器。很多人习惯在拦截器里统一处理业务状态码，比如判断返回的 code 字段不是 0 就认为失败，顺手写了个 return Promise.reject(response.data)。这样即便 HTTP 状态码是 200，Promise 链在拦截器这一层就转入了 rejected 状态，后面的 then 永远收不到，直接进了 catch。如果你也在拦截器的成功回调里调用了 Promise.reject，那就得留意是不是把正常响应也错当成了错误。

正确的做法是，只有确定需要走异常流程时才 reject，否则就正常 return response，让调用方自己处理业务上的成功或失败分支。

另一个经常碰到的是响应数据格式和预期不一致。假设前端用 Axios 默认配置发了一个请求，期望后端返回 JSON，但后端因为某种原因（比如报错页面、网关重定向）返回了一段 HTML 或者纯文本，Axios 内部会尝试 JSON.parse，解析失败就会抛出错误，即使状态码 200 也没用，最终还是在 catch 里看到。查这类问题时，别光看状态码，重点看一眼 Response Headers 里的 Content-Type 和实际返回的响应体，很可能后端改成 text/html 了你却没注意到。

解决方法要么让后端按约定返回正确的格式，要么在 Axios 请求里显式指定 responseType（比如 text），拿到数据后自己手工解析。

跨域问题这个看起来跟 200 状态码有点矛盾，但确实可能发生。

浏览器会在某些场景下先拿到一个 200 的响应，然后由于 CORS 头缺失或者不规范，拒绝把这个响应交给 JavaScript，Axios 收到的就是一个网络层面的错误，最终进入 catch。虽然浏览器控制台一般会打出 CORS 报错，但如果你的请求被一些代理层处理过，或者服务端只对 OPTIONS 预检请求返回了正确的头，对实际 POST 响应却没带全，就可能出现 Network 里看着 200、代码却走进 catch 的情况。这时需要检查服务端返回的 Access-Control-Allow-Origin 等头，确保不仅预检通过，实际接口响应也携带了允许跨域的头信息。

如果你的项目里用了 CancelToken 来做重复请求的取消，或者自己封装了取消逻辑，也要小心误伤。有时候取消的 token 可能在请求过程中因为状态变更而被提前执行了，导致 Axios 直接 cancel 掉一个本该有效的请求。

被取消的请求也会进入 catch，响应状态码可能还没来得及发挥作用就被丢弃了。这种情况可以先临时去掉取消逻辑，看问题是否消失，然后逐步收紧取消的条件。

最后一种比较少见，跟网络或服务器配置有关。比如响应已经到了客户端，但连接突然中断，或者服务器返回的响应头里带了畸形的 Content-Length，导致 Axios 认为响应不完整而报错。这种情况 Network 面板里可能显示 200，但其实是浏览器在传输结束时给的一个标记，并不代表客户端完整消费了响应体。

证书到期前，lcjmSSL系统会提前发出提醒通知，用户可以通过短信、邮件或微信小程序了解证书状态。平台还提供了自动化证书更新功能，确保用户的网站始终保持最新的安全证书，避免因证书过期而导致的安全隐患。

遇到的话可以检查一下有没有代理、CDN 或者 WAF 在中间截断了连接，或者抓个包看看完整的响应头。

上面这些原因按频率排个序的话，我遇到的大头还是拦截器误判和数据格式不匹配。每次碰到这类问题，可以先关掉全局拦截器试一下，或者用 Postman 拿到原始响应和请求时的头，大概就能定位到是哪一层出了问题。