前端获取http状态码400的返回值实例

在日常开发中，调用后端接口时，最怕遇到什么？其实不是报错，而是报错之后你拿不到有用的信息。比如，后端告诉你“手机号已存在”，返回了一个400状态码，可你的前端代码却只捕获到一个光秃秃的Error对象，连个数据都捞不着，那才叫抓狂。

下面这段代码，就展示了如何正确地拿到400状态码背后的真实数据，而不是只看到一句“Error: Request failed with status code 400”。

axios.get("/check_mobile_and_sent_code",{
  withCredentials:true,
  params:{mobile:formInline.mobile}
}).then(res=>{
  console.log(res);
  // 倒计时逻辑，这里略——关键看error处理
  if (!this.timer) {
    this.count = this.TIME_COUNT;
    this.show = false;
    this.timer = setInterval(() => {
      if (this.count > 0 && this.count <= this.TIME_COUNT) {
        this.count--;
      } else {
        this.show = true;
        clearInterval(this.timer);
        this.timer = null;
      }
    }, 1000)
  }
}).catch(error=>{
  console.log(error.response.data);
  console.log(error.response.status);
  console.log(error.response.headers);
  console.log('Error', error.message);
  console.log(error.config);
})

使用场景：

当后端判断验证的手机号已存在时，会返回400状态码。这时候，如果没有在catch里正确打印error.response，你看到的只是error.message，也就是一串“400 (Bad Request)”，根本不知道具体原因。而上面的代码，通过error.response对象，就能拿到后端返回的详细数据——比如错误描述、业务码等。

下面这张图，就是在控制台打印出来的error.response的实际内容，可以看到，状态码、请求头、响应体都清清楚楚。

这里有个容易踩的坑：如果直接输出error，它等于error.message，而不是完整的响应对象。一定要用error.response才能拿到后端的返回数据。

作为对比，再来看看状态码200时的正常返回值是什么样的——

总结一下：处理HTTP错误时，别只盯着error.message，error.response才是你真正需要的好东西。拿到它，你就能精准定位后端返回的业务错误信息，再也不用对着400状态码干瞪眼了。