Q07：如果给你一个体积庞大的老 Webpack 项目，打包需要 5 分钟，让你去做构建提效，你会从哪些维度排查和优化？能说出具体的配置手段吗？
⏱ 预计阅读时间：4 分钟
原题：如果给你一个体积庞大的老 Webpack 项目，打包需要 5 分钟，让你去做构建提效，你会从哪些维度排查和优化？能说出具体的配置手段吗？
🎯 面试官在考什么
- 考点1：构建提效的系统性思路（不是背配置，而是有方法论）
- 考点2：缓存、多线程、编译器替换三大加速手段的具体配置
- 考点3：产物体积优化的分包与压缩策略
✅ 答题框架（建议顺序）
- 先说排查思路：用
speed-measure-webpack-plugin定位耗时最长的 Loader/Plugin → 用webpack-bundle-analyzer分析产物体积分布 → 区分"构建速度慢"和"产物体积大"两个维度分别优化 - 再说构建速度优化：①开启 Webpack 5 持久化缓存
cache: { type: 'filesystem' }（二次构建提速 60%+）②用 thread-loader 并行处理 CPU 密集型 Loader（如 babel-loader）③用 swc-loader 替代 babel-loader（Rust 编写，快 10-20 倍）④缩小 Loader 处理范围include/exclude - 最后说产物体积优化：①
splitChunks分包策略——分离 vendor/公共模块 ② Tree-shaking（sideEffects + ESM）③ 动态 import 懒加载非首屏路由 ④ Gzip/Brotli 压缩 ⑤ Externals 外部化大型库（如 React/Vue 走 CDN）
⚠️ 常见踩坑
- 上来就说"开缓存、用 thread-loader"，跳过排查 → 面试官想听的是方法论，不是配置清单。先分析瓶颈再对症下药
- 认为
cache: { type: 'filesystem' }万能 → 持久化缓存首次构建不生效（反而稍慢），只有二次构建才大幅提速。且 CI 环境需要配置cache.name或缓存目录持久化才有意义 - thread-loader 无脑全上 → thread-loader 有进程通信开销，小文件或快 Loader（如 css-loader）反而变慢。只对 CPU 密集型 Loader（babel-loader、ts-loader）有意义，且需
workers: require('os').cpus().length - 1合理配置
💎 加分项
- 提到 swc-loader / esbuild-loader 替代 babel-loader 的实战效果，如"替换后单 Loader 耗时从 30s 降到 2s"
- 提到 CI 缓存策略：将 Webpack 的
cache.directory挂载到 CI 的缓存卷，避免每次流水线全量构建 - 主动给出量化指标意识："优化前 120s → 持久化缓存后 20s → swc 替换后 12s → 分包后首屏从 8MB 降到 2MB"，用数据说话
📚 关键知识点速查
- 持久化缓存：Webpack 5 的
cache: { type: 'filesystem' }，将首次构建结果写入磁盘，二次构建只重新编译变更模块 - thread-loader：Webpack 官方多线程 Loader，在单独的 worker pool 中运行后续 Loader，适合 CPU 密集型转换
- swc-loader：基于 Rust 编写的 SWC 编译器的 Webpack Loader，替代 babel-loader 速度快 10-20 倍
- splitChunks：Webpack 的代码分割配置，通过
cacheGroups将公共依赖、第三方库拆分为独立 chunk - Externals：将特定依赖从打包中排除，运行时通过 CDN 或全局变量引入，减少打包体积和构建时间
- speed-measure-webpack-plugin：测量每个 Loader/Plugin 耗时的分析工具，构建优化的排查起点
优先级：🔴高频
