包体积超限问题
背景
某日发布节点后，监控平台发现包体积超限，增长很多，于是拉了各个业务方进行排查
排查
我这边用 webpack-bundle-analyzer 发现增长的体积和懒加载的代码体积刚好对得上，怀疑是不是懒加载代码加载的时间提前了，代码有循环引用之类的，导致应该懒加载的代码，提前加载进来了。但是逐一查看改动代码，没有发现循环引用的情况。
又看了下监控的数据，发现统计的数据是不稳定的，在这之前也有部分数据超限，感觉统计代码的脚本不是很稳定，于是又去看统计代码体积的脚本。
看了代码，发现统计脚本是在插件加载完成后使用 performance.getEntriesByType 来获取所有加载的 script 资源的体积数据。
又想到前两天上线的一个 如何实现全局图片监控 的功能中，有一行代码是改动了 performance 的缓存空间大小
performance.setResourceTimingBufferSize(2000) |
于是怀疑是不是这个改动影响了统计代码体积的脚本，于是把这段代码删掉，重新发布，发现包体积恢复’正常’。
把这个size改为一个小值，跑一下脚本，发现统计的数据更少了，说明这个改动确实影响了统计代码体积的脚本。
看了下这个 setResourceTimingBufferSize，这个接口用于设置浏览器资源计时缓冲区的大小。
这个缓冲区用于存储页面加载过程中各种资源的性能数据，例如加载时间、传输时间等。这些数据可以通过 Performance 接口进行访问和分析。
当缓冲区达到设定的最大大小时，新的资源计时数据会替换掉最早的数据。这意味着，如果缓冲区已满，最早进入缓冲区的数据会被新的数据覆盖。
这个值不手动设置默认是 250， 又手动看了下打开页面后的资源大概多少，发现数值在 400 左右，所以初始的值 250 统计的值可能是偏小的，部分数据被丢掉了，数据不准确。
把这个问题反馈上去，调整统计体积脚本的代码，设置了一个较大值去统计所有初始加载的资源，包括部分 prefetch 的懒加载代码，以调整后的资源大小作为基线去评估后面的包体积增长情况。
总结
这次排查总的来说还是比较幸运的，还是需要从代码和监控数据入手，大胆假设，小心求证。
- webpack-boundle-analyzer 可以用来查看打包后的体积分布情况
- performance.getEntriesByType 可以用来获取所有加载的资源的体积数据
- performance.setResourceTimingBufferSize 可以用来设置 performance 的缓存空间大小，这个改动可能会影响 performance.getEntriesByType 的结果