webpack 性能优化

换掉 babel-loader 的风险

把 module.rules 里的 babel-loader 换成 esbuild-loader，target 交给 esbuild，收益是数量级的编译提速。风险在语义差异：emitDecoratorMetadata（NestJS/Angular）esbuild 不支持；babel-plugin-import、styled-components 的 babel 插件全部失效；class 字段语义可能与 tsc 默认值不同。判断标准是项目里有没有必须在 AST 层改写代码的 babel 插件。

三、产物体积：分包与摇树

splitChunks 的默认策略

默认值里最要命的一条是 chunks: 'async'——只对 import() 产生的 chunk 生效，同步引入的 node_modules 全部留在入口 chunk。「配了 splitChunks 但 vendor 没拆出来」几乎都是这个原因。

optimization: {
  splitChunks: {
    chunks: 'all',
    minSize: 20000,
    maxInitialRequests: 5,
    cacheGroups: {
      react: { test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
               name: 'react', priority: 30, chunks: 'all' },
      vendor: { test: /[\\/]node_modules[\\/]/, name: 'vendor',
                priority: 10, chunks: 'all', reuseExistingChunk: true },
      common: { minChunks: 2, priority: 5, chunks: 'all' },
    },
  },
  runtimeChunk: 'single',
}

priority 大的先匹配，reuseExistingChunk 避免同一模块复制进多个组。react 单独成组是因为它几乎不变，独立文件让 contenthash 长期稳定。

runtimeChunk 为什么单独拆

runtime 里存着「模块 id → 文件」的映射表和 chunk 加载逻辑。业务代码增删模块，id 就变，映射表随之变化；runtime 混在 vendor 里，每发一次版 vendor 的 contenthash 就全变，浏览器缓存彻底失效。多入口用 runtimeChunk: { name: (e) => \runtime-${e.name}` }`。

Tree shaking 的三个前提

// 1. 源码必须是 ESM；2. package.json 声明副作用；3. production + 标记 + 压缩
{ "sideEffects": ["*.css", "*.global.js"] }
optimization: { usedExports: true, sideEffects: true, providedExports: true, minimize: true }

usedExports 只做标记（代码旁加注释），删除由 Terser 完成；开了 production 但没开 minimize 时体积不会下降。

minimizer 与 drop_console

optimization: { minimizer: [new TerserPlugin({
  parallel: true,
  terserOptions: {
    compress: { drop_console: true, pure_funcs: ['console.log', 'console.info'] },
    format: { comments: false },
  },
  extractComments: false,
})] }

drop_console 会把 console.error 一并删掉，线上排障能力归零。多数团队该用 pure_funcs 精确指定。

按需引入与 babel-plugin-import

antd v4 及更早版本会把整包样式带进来，靠 babel-plugin-import 在编译期改写成 antd/es/button；v5 改为 ESM + CSS-in-JS，本身可摇树，不再需要它。lodash 同理：import _ from 'lodash' 是 CJS 全量，换 lodash-es 具名导入才真能摇掉。

四、排查顺序

npx webpack-bundle-analyzer dist/stats.json   # 1. 先看构成
npm ls lodash react                           # 2. 找重复版本
node -e "const s=require('./dist/stats.json'); \
 s.modules.sort((a,b)=>b.size-a.size).slice(0,10) \
 .forEach(m=>console.log(m.size, m.name));"    # 3. 按体积排模块

顺序是：可视化看构成 → npm ls 找重复版本 → stats.toJson().modules 排序定位 → 才动配置。

五、常见误区

1. 以为 splitChunks 配了就一定拆出 vendor。默认 chunks: 'async'，同步依赖不参与；还要够 minSize，小包会被合并回入口。
2. 以为 thread-loader 线程越多越快。超过物理核数会频繁切换，每个 worker 独立内存，大项目容易 OOM。
3. 以为 drop_console 无害。它连 console.error 一起删，线上日志全丢；const c = console; c.log() 也处理不了。

面试怎么答

Q：二次构建为什么快？ filesystem cache 把每个 module 的构建结果（代码、依赖、hash）序列化到磁盘。二次启动按 snapshot 校验 mtime 与内容 hash，命中的模块直接复用，跳过 loader 与 AST 解析；buildDependencies 里的配置、loader 也参与校验，任一变化则整体失效。

Q：splitChunks 怎么配才有效？ chunks: 'all' 让同步依赖参与；cacheGroups 按优先级分组，把 react 这类长期不变的依赖单独成组；minSize 控制「小到不值得单独请求」的下限；maxInitialRequests 限制首屏并行数。配合 runtimeChunk: 'single'，否则 runtime 变化会让 vendor 的 hash 全失效。

Q：为什么不再用 DLL？ DLL 解决的是「依赖不重复编译」，代价是独立配置、额外 manifest、产物不可摇树、升级要手动重打。filesystem cache 达成同样目标且无需额外产物——它解决的是编译期问题，不是产物体积问题。

关联阅读

• webpack 核心概念与构建流程：chunk、module、asset 的区别与 stats 读法
• 构建工具原理与选型：Tree shaking 前提与体积排查总览
• 大体积媒体优化：JS 之外的图片、字体、视频治理