我的编程空间,编程开发者的网络收藏夹
学习永远不晚

从axios源码角度解决bug的过程记录

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

从axios源码角度解决bug的过程记录

现象

公司的一个 H5 站点在头条 App 里白屏,在手百、QQ 浏览器、Safari、Chrome 等都正常

排查思路

1. 引入 vConsole 在移动端调试

因为移动端没有 PC 里那样方便的调试工具可以清晰的查看 log 和 network 之类有用的信息,只能借助 vConsoleeruda 这类移动端调试工具,可以在移动端实现类似 PC 浏览器里的调试功能

2. 从大范围到小范围的 log

因为移动端无法 debugger,只能逐步的 log 去定位问题。我们采用的是 vue 技术栈,可以从 main.js 到路由组件的生命周期里去添加 log,通过这种方式定位到了在一个接口请求的方法之后的代码都不会请求,奇怪的是也没有抛出任何异常,并且在 vConsole 里的 network 下找到了该请求也是正常的响应,如下代码:

try {
    console.log('start fetch')
    const res = await FetchXXX();
    console.log(res)
} catch (e) {
    console.log(e)
}

只打印出了start fetch,请求的结果和捕获的异常里都没有打印出东西,至此又缩小了排查的范围,一定是请求的响应处理部分出现问题了。

因为我们的请求接口方法是基于 axios 统一封装的,本以为是封装的哪个环节有不兼容头条的代码,通过不断的 log,发现 request interceptor 都执行了,但是 response interctpor 一个都没执行,好家伙,看着不像我们封装的问题,应该是 axios 内部处理的问题。

3. axios 源码一览

通过上面的一顿操作,基本可以确认是 axios 内部处理响应数据时可能有部分兼容性问题,去 github 上去找 issue 也没找到相关的问题。 没办法只能去看 axios 的源码了,我们前面定位到是请求发送没问题,在响应的时候应该是遇到了啥异常,并且还没有抛出。

项目里 axios 用的版本是 0.24.0,我直接在 node_modules 里看 axios 的源码,因为 npm 下载的 axios 包没有用 webpack 或者 rollup 之类的编译过,所以在 node_modules 里看和看源码无异,并且更可靠(因为项目里是直接引用的这个代码)。打开 axios 源码目录

axios 的源码不算复杂,目录光看命名基本也能猜到是干啥的,几个主要目录如下:

adapters:针对不同的宿主环境使用不同的请求 api,目前只有浏览器端和 nodejs 端,adapters 目录下的 xhr.jshttp.js 分别对这两种环境进行了实现。

cancel:取消请求的相关源码

coreaxios 的核心源码

helpers:工具方法

排查角度 - interceptor

之前定位到所有的 response interceptor 都没执行,根据这个现象我先找到 interceptor 相关的代码,在 core/Axios.js 里找到以下代码:

// 请求拦截器列表
var requestInterceptorChain = [];
var synchronousRequestInterceptors = true;
// 遍历所有的请求拦截器并放入到列表中
this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {
    if (typeof interceptor.runWhen === 'function' && interceptor.runWhen(config) === false) {
        return;
    }
    synchronousRequestInterceptors = synchronousRequestInterceptors && interceptor.synchronous;
    // 请求拦截器后进先出(栈)
    requestInterceptorChain.unshift(interceptor.fulfilled, interceptor.rejected);
});
// 响应拦截器列表
var responseInterceptorChain = [];
// 遍历所有的响应拦截器并放入到列表中
this.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {
    // 请求拦截器先进先出(队列)
    responseInterceptorChain.push(interceptor.fulfilled, interceptor.rejected);
});
var promise;
if (!synchronousRequestInterceptors) {
    // axios执行队列,包含所有的请求拦截器、请求方法、响应拦截器,并按顺序排列
    // 这里的dispatchRequest就是实际的请求方法
    var chain = [dispatchRequest, undefined];
    // 将所有的请求拦截器放请求的前面
    Array.prototype.unshift.apply(chain, requestInterceptorChain);
    // 将所有的响应拦截器放请求的后面
    chain = chain.concat(responseInterceptorChain);
    promise = Promise.resolve(config);
    // 依次执行整个执行队列,直至队列为空
    while (chain.length) {
        promise = promise.then(chain.shift(), chain.shift());
    }
    return promise;
}

以上代码就是 axiosinterceptor 核心的处理,一开始怀疑是不是所有的响应拦截器没有被加入到执行队列中,log 后发现没有问题,所有响应拦截器都在队列中。

排查角度 - xhr

上面排除了 interceptor 的问题,我又怀疑 axios 封装的 xhr 在响应的时候有啥兼容性问题,于是查看 adapters/xhr.js,并找到处理响应相关的代码:

// 省略了许多不必要的代码
var request = new XMLHttpRequest();
function onloadend() {
    console.log('onloadend')
    // ...
}
if ('onloadend' in request) {
    console.log('use onloadend')
    request.onloadend = onloadend;
} else {
    console.log('use onreadystatechange')
    request.onreadystatechange = function handleLoad() {
        if (!request || request.readyState !== 4) {
            return;
        }
        setTimeout(onloadend);
    };
}

axios 处理响应的代码大致如上,如果浏览器 xhr 对象包含 onloadend 事件就监听 onloadend 事件,否则监听 onreadystatechange 来实现请求响应的回调,通过 log 我发现打印了use onreadystatechange,但是没打印onloadend

至此终于找到问题所在,头条 iOS 该版本的 xhr 对象虽然声明了 onloadend 事件但是请求结束后并未回调该事件!

4. 解决问题

因为我们其他站点在头条上是可以正常访问的,我看了那些站点的代码,发现他们用的 axios 版本是 0.18.1,看下 0.18.1 版本的 adapters/xhr.js 文件对于响应的处理:

他是直接使用的 onreadystatechange 方法来监听的,所以没有问题。

至此整个排查结束,最后通过降级 axios 版本解决该问题。

以上就是从axios源码角度解决bug的过程记录的详细内容,更多关于axios源码角度bug解决的资料请关注编程网其它相关文章!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

从axios源码角度解决bug的过程记录

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

从axios源码角度解决bug的过程记录

这篇文章主要为大家介绍了从axios源码角度解决bug的过程记录,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
2022-12-15

Android图片加载框架最新解析:从源码的角度理解Glide的执行流程

文章目录准备源码开始阅读1、with()2、load()3、into()总结 众所周知Glide是Android开发中普遍使用的图片加载框架,功能非常强大,API非常简便,也是Google官方唯一推荐的图片加载框架。 基本用法,本文不再叙述
2022-06-06

编程热搜

目录