webpack 的优化点很多，容易让人抓不住重点。其实可以按目标分成四类：让开发更舒服、让构建更快、让产物更小、让运行更快。本文做一次提纲式总结，每个方向列出常用手段和关键配置，方便按需查阅。

一、提升开发体验

目标是「改完立刻看到效果，出错一眼定位」。

要点：开发环境追求「快 + 好调试」，所以 devtool 选便宜的、CSS 用 style-loader、产物名不加 hash。

二、加快打包构建速度

核心思路：少做无用功、复用上次结果、能用多核就用多核。

1. 缩小处理范围

{
  test: /\.m?js$/,
  include: path.resolve(__dirname, 'src'), // 只处理源码
  exclude: /node_modules/,                 // 排除第三方
  use: 'babel-loader',
}

• include / exclude：避免对 node_modules 全量执行 loader。
• oneOf：命中一条规则即停止，减少规则匹配。
• resolve 优化：减少查找范围。

module.exports = {
  resolve: {
    extensions: ['.js', '.jsx'],      // 少写几个后缀，减少尝试
    modules: [path.resolve(__dirname, 'src'), 'node_modules'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
    },
    symlinks: false,
  },
};

2. 缓存复用

module.exports = {
  cache: {
    type: 'filesystem',           // webpack 5 文件系统缓存
    buildDependencies: { config: [__filename] },
  },
};

• cache: { type: 'filesystem' }：跨构建复用模块处理结果，收益最大。
• babel-loader 的 cacheDirectory: true：复用 Babel 转译结果。
• eslint-webpack-plugin 的 cache: true：复用 ESLint 检查结果。

3. 并行与更快的工具

• thread-loader：把耗时的 loader 放到 worker 线程。
• terser-webpack-plugin 的 parallel: true：多进程压缩（生产环境下默认开启）。
• swc-loader / esbuild-loader：用 Rust/Go 实现的转译器替代 Babel，速度可提升数倍。

4. 跳过不必要的解析

module.exports = {
  module: {
    noParse: /jquery|lodash/, // 确定无依赖的库不再解析
  },
  externals: {
    // 大库走 CDN，不打进产物、也不参与构建
    react: 'React',
    'react-dom': 'ReactDOM',
  },
};

5. 关闭不必要的产出

• 开发环境不抽离 CSS（用 style-loader）。
• 减少统计信息输出：stats: 'errors-only'。
• 生产环境用 hidden-source-map，避免生成/暴露完整 map 的开销与风险。

三、减少代码体积

目标是「下载的字节更少」，包含压缩、拆分、按需三方面。

1. Tree Shaking

• 使用 ESM（import / export），避免 CommonJS。
• package.json 声明 sideEffects，注意把 CSS 列入。
• Babel 保留 ESM：modules: false。

2. 代码分割

optimization: {
  runtimeChunk: 'single',
  splitChunks: { chunks: 'all' },
}

• 动态 import()：路由、弹窗、重型功能按需加载。
• splitChunks：抽取公共依赖与第三方库。
• runtimeChunk：隔离运行时，稳定入口 hash。
• prefetch / preload：提前加载可能用到的 chunk。

3. 压缩与删除

4. 按需引入与瘦身

• polyfill 按需：useBuiltIns: 'usage' + 合理的 browserslist。
• 组件库按需加载：避免整包引入（babel-plugin-import 或 ESM 按需）。
• 去重：resolve.alias / resolve.dedupe 避免同一库多版本打包。
• 忽略无用模块：如 moment 的语言包，用 IgnorePlugin 剔除。
• 体积分析：webpack-bundle-analyzer 找出大块头再针对性优化。

// 忽略 moment 的多余语言包
plugins: [
  new webpack.IgnorePlugin({
    resourceRegExp: /^\.\/locale$/,
    contextRegExp: /moment$/,
  }),
],

四、优化代码性能

目标是「产物加载后运行得更快，用户感知更流畅」。

1. 作用域提升（Scope Hoisting）

optimization: {
  concatenateModules: true, // 生产默认开启
}

把多个模块合并进同一作用域，减少函数包裹和模块查找开销，代码更小也更快。

2. 首屏与加载性能

• 代码分割 + 懒加载：首屏只加载必要代码，降低主线程压力。
• prefetch / preload：提前拉取后续资源，减少等待。
• 合理拆分第三方库：利用浏览器并行下载能力。
• externals + CDN：大库由 CDN 分发，减少自建产物体积。

3. 缓存友好（长期缓存）

output: { filename: 'js/[name].[contenthash:8].js' },
optimization: {
  runtimeChunk: 'single',
  moduleIds: 'deterministic',
  chunkIds: 'deterministic',
},

内容不变则 hash 不变，用户二次访问直接命中缓存，这是「感知性能」提升最显著的一环。

4. 运行时与传输

• 避免重复执行：Tree Shaking 减少无用代码执行。
• 控制 polyfill 规模：browserslist 越精准，运行时负担越小。
• 图片优化：压缩、转 WebP/AVIF、响应式尺寸，可直接改善 LCP。
• 按需 polyfill 与副作用清理：避免引入用不到的大量兼容代码。

5. 先测量，再优化

• webpack --profile --json > stats.json：分析耗时与模块。
• webpack-bundle-analyzer：定位体积大户。
• Chrome DevTools 的 Performance / Coverage：看运行时瓶颈与代码利用率。

五、整体对照表

六、注意事项

1. 优化要有依据：先量化（构建耗时、产物体积、运行时指标），再针对性优化，不要盲目堆配置。
2. 开发与生产分开：开发求快、生产求小，用 webpack-merge 拆分配置。
3. 缓存是双刃剑：filesystem cache 和长期缓存都可能带来「改了没生效」的困惑，注意失效与清理策略。
4. 避免过度优化：规则过细、chunk 太碎、polyfill 过度都会适得其反。
5. 不要过早优化：项目规模不大时，优先保证配置清晰、可维护。

小结

webpack 的优化可以浓缩成四句话：

• 开发体验：devServer + HMR + 合适的 devtool，让改动即时可见。
• 构建速度：缩小范围 + 缓存 + 并行，让重复工作不再重复。
• 代码体积：Tree Shaking + Code Splitting + 压缩，把产物压到最小。
• 运行性能：Scope Hoisting + 懒加载 + 长期缓存，让页面加载和运行都更快。

按这四个方向逐项检查，再结合量化数据取舍，就能搭建出一套既高效又易维护的构建配置。