做 webpack 优化前，先用 bundle report 看清到底是谁把包撑大了

webpack 的性能优化很容易让人一上来就陷入“经验动作”：先怀疑 UI 组件库，再怀疑图片，再想办法加几个拆包配置。可如果还没看清产物里到底是什么占了体积，这些动作大多只是碰运气。真正有效的优化，通常都从一份可读的打包分析开始。

先回答“是哪个 chunk 大”，再问“为什么大”

很多项目报性能警告时，只知道入口文件超了，却不知道是业务代码变大、公共依赖变大，还是同一份库被重复打了几次。没有这个基础判断，后面的优化建议很容易南辕北辙。

我比较习惯先拿到产物体积分布：入口包、异步包、公共包、运行时代码分别多大。先确认问题主要集中在哪一类，再进一步追是谁把体积抬上去。这样讨论才不会一直停留在“感觉可能是某某库太重”。

可视化报告最大的价值，是让重复依赖暴露出来

包变大不一定是因为用了“重型技术”，也可能只是同一类能力被重复引了几套。比如日期处理库混用了两种、图表组件同一页面挂了两份不同实现、一个库同时引入完整包和按需包。只看构建日志通常很难发现这种重复，分析报告里却会很显眼。

这也是为什么我不太喜欢在没有报告的情况下先拍脑袋优化。因为很多真正值得动手的问题，其实并不在“删掉某个大库”，而是在“为什么这份代码被打进来了两次”。

先建立基线，优化结果才有比较意义

如果没有一份明确的基线数据，优化很容易变成纯主观感受。一次改动后构建时间快了多少、主入口少了多少、首屏相关 chunk 有没有明显下降，这些最好都在开始前记下来。否则几轮调整下来，只会知道自己改了很多配置，却说不清到底值不值。

我现在更喜欢先把最大的几个 chunk 记一遍，再开始动代码和配置。这样每做一次调整，都能很快判断是有效收缩，还是只是把体积从一个地方挪到了另一个地方。

先看报告，是为了把优化从猜测变成决策

webpack 优化不怕做事多，怕的是方向一直不准。先有 bundle report，再决定要不要拆包、替换依赖、做按需加载，整个过程会更像工程判断，而不是经验主义堆叠。

很多时候，分析报告本身就已经在告诉你答案了。真正要做的，是先把它看明白，再动手。