负责的一个项目已经部署到客户的生产环境上测试了,接踵而来的是一系列的问题.这也算预料之中,无非是一些环境问题之类的. 但是有一个问题缺花了一天的时间来定位和解决.
发现的问题
客户那边现场的同事反馈说,有一个页面没数据.当时我一想肯定是后端接口因为什么环境问题报错,在客户的测试环境和我的本地环境都没啥问题.肯定不是前端的问题,果断把问题转给了后端同事.
一个小时后,后端同事排查发现,他们说没啥问题,环境也没问题,接口返回都是200,没报错,而且数据库的数据也是有的.看他说得这么笃定,而且也是工作经验2年的老员工了,他的判断应该没问题.不过我还是抱有一丝怀疑态度,就找客户现场同事复现了下问题,然后也排除了接口报错的原因.因为的确每个接口都是200的状态码,难道真的是前端问题?这个时候已经预感到一丝不妙,我感觉到这个问题不好解决,因为这个测试环境和本地环境都没问题,所以没办法复现.
解决方案
排除了后端的问题,那再怎么不可能,那也只有前端的问题了啊,没办法.开始定位问题呗.花了一个小时首先锁定出问题的代码文件,然后捋清逻辑, 然后花了一个小时反复debugger了这个只有200行代码的dva的models文件,的确没问题啊.又折腾了会,依然没搞明白这个bug产生的原因.
转眼下午到了,求助下大佬,大佬也觉得诡异,只说console.log输出下,然后打包到他们生产环境上测试下.反复增加console.log并打包和调试折腾了几个小时,终于让我捕捉到了一点诡异的信息,我发现程序有几个console.log没有输出.想了下,难道有报错?那也不对啊,报错了页面直接崩溃了啊,根本啥也看不到.难道是因为产生了异常,然后中断了?想到这,我发现了一丝希望,然后赶紧把dva的models文件里面yield call调用了函数全部try catch,然后输出下可能出现的异常,打包,测试.果然,控制台输出了一个异常: ‘某某表不允许Web server调用’.然后看下这个接口,状态码是200,但是reponse返回的业务代码 code = -3.但是根据以往的经验来看,只要是状态码是200,就算这个接口没正确返回也不会影响后面的代码运行啊.不过抱着试试想法,还是让后端同事把权限给了,解决了这个问题.最后,权限一给数据就出现了.
总结
虽然问题是解决了,但是我是想知道为什么会因为一个接口返回不正常,导致后面的代码不执行,因为以往的经验告诉我,就算有接口没返回数据,也只会这部分的数据不展示.后来翻看项目的封装的request请求的代码发现,只要业务代码 code <= 0.就直接promise.reject了不管你状态码是不是200..也算经验不足吧,不是很了解整个项目.这也提醒了我以后要多注意异常处理.