Webpack 的核心是模块图：从入口出发，分析依赖，把所有模块打包成浏览器可执行的 bundle。理解了这一层，你就知道优化点在哪里：依赖分析、代码分割、缓存与并行。
优化不是堆配置，而是理解瓶颈：是依赖太多？是重复打包？还是构建串行？对症下药才有效。
原则：先分析（用 stats/分析工具），再优化，一次改一个点，验证有效再继续。
常用优化手段按收益排序。
拆 chunk，按需加载，首屏瘦身。
摇掉未用代码，依赖按需引入。
缓存构建产物，二次构建秒级。
并行处理模块，大幅提速。
JS/CSS 压缩、图片压缩。
稳定依赖走 CDN，缓存命中高。
系统化的优化流程。
用 speed-measure 与 bundle 分析工具，记录构建时间与产物体积基线。
缓存、多进程、减少解析范围，先让构建变快。
代码分割、Tree Shaking、按需引入、压缩，逐项瘦身。
对比基线数据，确保功能完整、性能达标后固化配置。
按环节整理的优化清单。
| 环节 | 手段 | 预期收益 |
|---|---|---|
| 依赖解析 | 配置 alias/exclude | 减少无效解析 |
| 构建速度 | thread-loader/缓存 | 提速 40%+ |
| 产物体积 | 代码分割/Tree Shaking | 缩减 30%+ |
| 首屏加载 | 按需加载/懒加载 | 首屏明显变快 |
| 缓存命中 | CDN 拆分/指纹 | 二次访问更快 |
先量化：看是解析慢还是压缩慢。常见解法：持久化缓存、多进程、缩小 loader 范围、减少不必要的插件。
用 webpack-bundle-analyzer 可视化分析，找到体积大头，再做按需引入与拆包。
会。拆分后要注意公共依赖的 chunk 策略、加载时序与缓存冲突，做好回归测试。
新项目优先 Vite；Webpack 的价值主要在存量工程。两者不必二选一，团队可并存过渡。
