Webpack打包十六进制转十进制异常引发的白屏惨案

非典型问题，不具备普适性，出现难度高，本文仅做问题排查历程分享

前言

为了最大化利用浏览器的缓存，我们针对不同的模块文件名设置了 chunk/[name].[contentHash:6].js，表示仅截取 contentHash 的后 6 位，默认是 20 位。

结果在某次集成后，部署完发现页面白屏了，发现 js 文件里面有这么一个错误

通过异常的上下文，搜索临近的变量或方法名，定位到源码大概是下面这个位置👇🏻

验证

分析 Webpack 打包时是靠 acorn 库对十六进制进行十进制转换的

尝试单独拿这组十六进制数据这个库在打包机环境里进行编译，发现编译结果正常的

重新从主线拉代码集成出来看产物，发现这个 32223cd714 问题还是存在，觉得莫名其妙

主线新建了一个分支，然后集成这个分支的代码（源码完全一致，yarn.lock 文件也有提交），出来的结果又正常了

当天没有定位到问题，第二天重新集成的时候奇迹般的恢复正常了

彻底疯狂ing

怀疑过代码，怀疑过打包机，怀疑过系统时间，怀疑过 gitlab 分支目录，现在已经开始怀疑人生了

重点就在于，本地编译无法复现，似乎只在打包机环境存在该问题，这就让问题排查变得十分困难了

山重水复无疑路啊

思考

为什么其他项目同一台打包机编译的时候都没有出现类似的问题？
为什么编译配置很久没有调整过了，现在突然出现了这个问题？
为什么同一套代码换到分支上就正常了？
为什么当天反复编译都会出现这个错误，而且每次重复编译错误的位置和内容也是一模一样？
为什么过了两天就正常了，一个月后又出现了这个问题，只不过换了一个十六进制的位置？

一波五连问，开始抽丝剥茧。。

和其他项目对比，编译配置的区别只有这个项目 output 配置了 [contentHash:6] 其他项目默认都是以[name]作为文件名导出。

打包机最近才出现，而且本地无法复现，打包机有没有什么调整？（运维人员表示不存在调整）

条件变量：

编译配置不一样
机器日期时间不同
导出目录名称不同，导入分支名称不同

上述几个变量，需要均满足某个条件的情况下，才会出现这个问题。

换了其他人的电脑

分析

机器日期

结论：很不现实，发包日不可能等

导出目录名称

原因：修改导出名称，可以让集成结果正常

结论：也不现实，总不能遇到一次修改一次，不彻底

修改编译配置

原因：导出配置仅包含[name]时，集成结果正常；改回[contentHash:6]则集成结果异常

结论：还是得保留[contentHash]

猜测：会不会是[contentHash:6]导致的？

那有没有什么办法不用[contentHash:6]模板的方式呢？

有了这个属性，就可以不用 :6 的写法了

调整后配置如下：

js 复制代码

output: {
  filename: "js/[name].[contenthash].js",
  chunkFilename: "chunk/[name].[contenthash].js",
  hashDigestLength: 6,
  path: path.resolve(__dirname, "../dist/h5"),
}

这样试了一次，果然集成结果正常了，而且文件名也是支持 contentHash 的。

总结

花了很多时间定位，排查，思考，最终还是没能彻底研究明白为啥转换是异常的，Webpack 依赖了 acorn 库对十六进制进行十进制转换，即使看了源代码，也没能从代码上发现什么原因。

但从目前收集到的信息来看，似乎这样做是可以避免此种编译异常的，做一次技术分析记录，后续如果还出现的话，再继续跟进。