记一次打包失败的bug定位过程，总结方法论

测试反馈Jenkins打包失败，截图了错误日志。

 

本地跑了一下打包命令，可以复现报错日志。

 然后复制报错信息问chatgpt

 

告知错误 

TypeError [ERR_INVALID_ARG_TYPE]: 第一个参数必须是字符串或Buffer、ArrayBuffer或Array的实例，或类似数组的对象。收到了undefined。

　　还是一头雾水

但同时告知去查看 

 /weixin_ci/gulp/tasks/production/jsCoverage.js:  这个文件第132行

所以给content和data.code 打个log输出， 因为Jenkins就是跑本地提供的命令，所以试着在本地打包命令，复现了截图的报错。同时content定位出了是哪个文件报错， 而data的log定位出来报了什么错误，代码第几行报错

 原本data应该输出一个对象传入buff.from的， 但因为报错进而导致了Jenkins的报错 

TypeError [ERR_INVALID_ARG_TYPE]: 第一个参数必须是字符串或Buffer、ArrayBuffer或Array的实例，或类似数组的对象。收到了undefined。

现在知道了哪个文件报错已经报错的行数，打开文件查看查看发现是使用了可选链语法(?.)导致的， 询问得知可选链需要node14以上版本支持， 我本地node版本16，运行正常，但估计打包环境的node版本不支持 可选链语法(?.)才会导致打包失败。

 

总结：

1： 为什么chatgpt能在报错日志中众多文件精确找到    /weixin_ci/gulp/tasks/production/jsCoverage.js: 这个文件第132行。 观察了一下，这个文件下面的报错都是node_module下的文件，可以忽略这些文件

 而buffer.js， events.js, domain.js 应该是js底层的文件，也可以忽略，最后剩下的jsCoverage.js是项目中的代码，就只能是他了。定位到报错位置就成功一半了。

2：找到报错代码位置后，可以打log，查看控制台输出，查看报错信息。

3：这种隐晦的报错，无法通过单纯的复制，搜索报错信息。问chatgpt。 直接定位出具体的报错原因。需要通过上面的排查推断