一次艰难的debug过程

最近上线了新功能,前端需要将新功能的代码打包,然后部署在新的域名的服务器上。打完包,将包扔给了运维,我便开始学习,以为万事大吉了。

然而同事突然跟我说,访问新的域名竟然重定向到了测试环境的登录页面,也就是dv-ucenter.xxxx.com/login,但正确的地址应为线上的登录地址: t-uncenter.xxxx.com/login

插一句,登录页面代码不存在于我们的前端项目里,而是由其他业务线编写,域名也由其他业务线负责,所以就算换了新域名,登录页面地址依旧不变!

由于现象过于明显,所以很快便定位到了问题,我们项目中基于axios的请求方法中存在这么一段代码:

1
2
case StatusCodeEnum.UCENTER_TOKEN_INVALID:
    window.location.href = window.__CONFIG__.login;

window.__CONFIG__.login这个变量是通过当前页面的地址是由t开头,还是由dv开头来决定。新的域名并不满足于此逻辑,既非t开头也非dv开头,所以它最终跳错了。时间紧急,赶紧在window.__CONFIG__.login的赋值处强行判断,如果window.location.host等于新的域名那么也要跳转到t-uncenter.xxxx.com/login

1
2
3
4
5
6
//原来的逻辑
login = '//' + window.location.host.split('-').shift() + '-' + '%REACT_APP_LOGIN%',

// 修改后:
var hostPrefix = window.location.host === 'xxxx(新的域名)' ? 't' : window.location.host.split('-').shift();
login = '//' + hostPrefix + '-' + '%REACT_APP_LOGIN%'

改完以后重新打包,给运维,一切行云流水,甚至有点小得意,觉得自己debug的能力越来越强了。然而事情总是不会按照想象发生,重新部署以后发现,连了公司的VPN的话,就会跳转到错误的登录地址:dv-ucenter.xxxx.com/login,不连公司VPN的话,就会跳转到正确的登录地址: t-ucenter.xxxx.com/login

说实话我有点慌了,因为我很确定我的改动没有问题,但事情却没有按照预期发展。后端同事看到以后帮忙让运维检查部署的两个节点是不是代码不一样,最后发现也是一样的,如此便排除了服务器配置的原因。

就在不知道该如何解决时,突然想起来我们的代码引用了别的业务线的两个公共组件HeaderMenu,目测是这出了问题。赶紧给这个业务线的前端负责人打电话,最终这个负责人告诉我,他们的代码里也做了如果未登陆就会重定向到登录页面的判断,他们也是跟我们选用了一样的判断方法,根据是不是t开头来重定向,是的话就是t-ucenter.xxxx.com/login,否则就是dv-ucenter.xxxx.com/login

那为什么会存在VPN连不连两种现象呢?其实是因为他们的这两个组件最开始会发送一个AJAX请求,这个请求的前缀,由于我们的域名不符合t开头,所以前缀变为dv,而他们的重定向逻辑也是封装在axios中的:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
return axios(defaultConfig)
    .then((res) => {
        const status = res.data.status;
        // 成功的状态直接返回数据
        if (status.code == CODE) {
            return res.data.data;
        }
        else if (status.code == '2501') {
            window.location.href = REVIEWSCONFIG;
        }
        // else {
        //     Message.error(status.msg)
        //     // throw new Error(res.status);
        // }
    })

所以不连VPN的时候,因为他们请求的地址是dv开头,是内网地址,请求失败,他们的重定向逻辑根本没有被执行到!最终我们自己的项目里的重定向逻辑生效,也就是我最开始在上面做的改动那块,所以不连VPN,跳转的是对的。

然而当连了VPN以后,他们请求dv开头的请求在内网中是生效的了,所以他们的重定向逻辑最终被执行。我们的重定向逻辑也其实执行,只不过因为他们的请求成功得比较,所以最终的重定向逻辑覆盖了我们的重定向逻辑,他们的重定向地址因为我们的域名不符合t开头,所以最终跳转到了错误的地址。

其中还掺杂了本地HOST的配置,不在此赘述了。

最终的解决方案是在新的域名前面加上了t,这样的话任何人都不需要改代码了,有点惊讶,如此的随意~今天有空,所以想赶紧记录一下。

经过这件事情有几个点总结一下:

1️⃣:千万不要自己一个把所有的问题都揽下来,觉得自己是个「超能力者」,要适当地把锅甩出去,就像这个问题,最终的问题确实是出现在了别人的代码处。

2️⃣:遇到事情不要慌乱,这是来新公司的第一次上线,只有自己一个前端。遇到问题确实有点乱了,加上当时已经临近半夜,脑子也不太清楚了。

3️⃣:要对自己的项目门儿清,包括自己项目引用的库/依赖!就像如果我们知道我们引用的公共组件也有重定向的逻辑,那么最开始就知道问题出在哪。

updatedupdated2020-07-192020-07-19