您好,欢迎来到个人技术集锦。
搜索
当前位置:首页接口正常被调用且返回数据但前端页面渲染失败,控制台报错Uncaught (in promise)

接口正常被调用且返回数据但前端页面渲染失败,控制台报错Uncaught (in promise)

个人技术集锦 2025-06-08
导读问题描述 接口正常被调用且返回数据但前端页面渲染失败,控制台报错 Uncaught (in promise) error Uncaught (in promise) error @ asyncToGenerator.js:6 Promise.then getDeivceList @ index.vue:103 mounted @ index.vue:124 Promise.then (匿名) @ permission.js:130 Promise.then (匿名) @ permi

问题描述

接口正常被调用且返回数据但前端页面渲染失败,控制台报错 Uncaught (in promise) error

Uncaught (in promise) error @ asyncToGenerator.js:6
Promise.then		
getDeivceList	@	index.vue:103
mounted	@	index.vue:124
Promise.then		
(匿名)	@	permission.js:130
Promise.then		
(匿名)	@	permission.js:130
(匿名)	@	permission.js:41
(匿名)	@	permission.js:32
Promise.then		
(匿名)	@	permission.js:29
Promise.then

这些Promise错误就像调皮的小鬼,在调用栈里上蹿下跳。最气人的是,在我本地环境竟然能复现!

解决思路(TL;DR:)

经过排查,发现:

导致产生这种情况的原因是:

  1. 后端同学未按照规范返回指定的响应码
  2. 前端同学在编写响应拦截器时未考虑更多的边界条件,未有错误预警。

破案之旅

先来一套"前端调试三板斧":

  1. 打断点追踪:从组件渲染层一路追踪到数据请求
  2. 查看网络响应:response里数据确实存在
  3. 数据类型校验:确定不是undefined在作妖
    当检查到响应拦截器时,突然眼前一亮
// 响应拦截器
service.interceptors.response.use(
  (res) => {
    // 未设置状态码则默认成功状态
    const code = res.data.code || 200;
    // 获取错误信息
    const msg = errorCode[code] || res.data.msg || errorCode["default"];
    // 二进制数据则直接返回
    if (
      res.request.responseType === "blob" ||
      res.request.responseType === "arraybuffer"
    ) {
      return res.data;
    }
    if (code === 401) {
      if (!isRelogin.show) {
        isRelogin.show = true;
        MessageBox.confirm(
          "登录状态已过期,您可以继续留在该页面,或者重新登录",
          "系统提示",
          {
            confirmButtonText: "重新登录",
            cancelButtonText: "取消",
            type: "warning",
          }
        )
          .then(() => {
            isRelogin.show = false;
            store.dispatch("LogOut").then(() => {
              location.href = "/index";
            });
          })
          .catch(() => {
            isRelogin.show = false;
          });
      }
      return Promise.reject("无效的会话,或者会话已过期,请重新登录。");
    } else if (code === 500) {
      // Message({ message: msg, type: "error" });
      return Promise.reject(new Error(msg));
    } else if (code === 601) {
      Message({ message: msg, type: "warning" });
      return Promise.reject("error");
    } else if (code !== 200) {
      Notification.error({ title: msg });
      return Promise.reject("error");
    } else {
      return res.data;
    }

这里有个很魔性的判断:code !== 200就会进错误处理。但你猜怎么着?后端同学在需求评审时说好的用200表示成功,结果上线时他们实际返回的code字段竟然是0!这就好比说好握手用右手,结果对方出左手。

于是当前端判断到code不是200时,直接触发reject:

// 原始代码判断逻辑
if (code !== 200) {
    Notification.error({ title: msg });
    return Promise.reject("error"); // 这里才是罪魁祸首
}

这导致调用链里的Promise异常没有被正确捕获,最终导致整个渲染流程崩溃。

后记

现在每次写拦截器都会留个后手:

我们给所有关键接口加了埋点监控,类似这样:

// 异常数据上报逻辑
if (unexpectedCode) {
    track({
        event: 'CODE_MISMATCH',
        payload: {
            expected: 200,
            actual: code,
            path: location.href
        }
    });
}

后记

现在每次对接新接口,我都会先确认这三个致命点:

  1. 状态码字段名叫code还是status?
  2. 正确的成功状态是数字类型还是字符串?
  3. 异常时的数据结构是否统一?

?? 后来跟后端兄弟撸串时聊起这事,他说自己当时看错了文档里的状态码定义… 果然是血与泪的教训啊!

Copyright © 2019- zgxue.com 版权所有 京ICP备2021021884号-5

违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com

本站由北京市万商天勤律师事务所王兴未律师提供法律服务