Webpack打包体积优化实战：5个核心手段让包体缩小80%

前一阵子接手了一个维护了两三年的后台管理项目，首屏加载时间一直徘徊在 3 秒左右，测试同事天天在群里艾特我。打开控制台一看 network，主 bundle 直接干到 4MB，chunk 加载完再解析执行，白屏时间长得能去倒杯水。用 webpack-bundle-analyzer 拉出来一看，好家伙，一个 echarts 就占了 800 多 KB，加上一堆老旧的 polyfill 和重复打包的组件库，整个包体早就“膨胀”得不成样子了。

说句实在话，webpack 打包体积这事，大部分团队都不是不想优化，而是不知道从哪下手。网上教程一搜一大把，但要么讲得太浅只给个配置片段，要么就是拿个 Demo 项目忽悠人，真正放到自己的业务代码里根本不适用。这篇文章我把自己在多个项目中验证过的 5 个核心优化手段完整写出来，包括怎么分析、怎么配置、怎么排查，每一步都有实际的配置代码和前后数据对比。不管你是刚接触 webpack 的初级前端，还是被构建产物折磨已久的资深开发，按这个思路走一遍，把包体缩小 60% 到 80% 是完全可复现的。

1. 动手之前先“体检”：打包体积分析与基线

1.1 为什么优化前必须先看数据

很多同学一上来就各种折腾配置，压缩、拆包、CDN 一顿操作猛如虎，最后一看打包产物，体积没小多少，反而多了几个加载失败的 CDN 依赖。这就是典型的“没诊断就开药方”。

打包体积优化跟看病是一个道理。你至少得先搞清楚这些问题：包体里面到底装了什么？哪些模块占了最大头？有没有同一个库被重复打包了多次？大块头是真需要还是误打进来的？这些信息不掌握，优化就是盲人摸象。我习惯在优化前先记录一份基线数据，包括总包体积、最大的几个 chunk、各 chunk 的 gzip 后体积、首屏请求数量，优化完以后拿这套数据再做对比，效果一目了然。

1.2 分析工具配置与输出解读

体积分析最常用的就是 webpack-bundle-analyzer，它能把打包产物渲染成一个交互式 treemap，每个矩形代表一个模块，面积越大说明体积越大，点进去还能看具体路径。

安装方式很简单：

bash复制npm install webpack-bundle-analyzer --save-dev

webpack 5 配置里加上这个插件：

javascript复制const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'static',
      reportFilename: 'bundle-report.html',
      openAnalyzer: false,
    }),
  ],
};

analyzerMode: 'static' 表示只生成一份静态 HTML 报告，不自动打开浏览器，适合在 CI 或者构建机上用。openAnalyzer 关掉自动打开，免得每次构建都弹个浏览器窗口烦人。

除了这个，还有个命令行工具 source-map-explorer 也不错，它能结合 source map 分析产物源码构成。不过日常用 webpack-bundle-analyzer 已经完全够用了，除非你想分析的是已经上传到 CDN 的线上版本。

1.3 摸清家底：我们到底载入了什么

拿我那个项目举个例子，分析报告拉开以后，问题清清楚楚：

• 总共打了 24 个 chunk，总原始体积 4.2MB，gzip 后 1.1MB。
• 最大的 chunk 是 vendor，2.3MB，里面 echarts、moment、lodash、axios 全挤在一起。
• echarts 一张图占了 800 多 KB，但项目里只用了它的折线图和柱状图。
• moment 全量引入了所有 locale，光语言包就 400 多 KB。
• 业务代码里 app.jsx 有 800 多 KB，里面混着一大堆只在某个页面用到的重型组件。
• 还发现 lodash 被打了两次，一次是 npm 包，一次是某个老插件内部依赖的副本。

这个体检结果说明，优化方向就非常明确了：大依赖需要按需引入或外部化、公共依赖需要拆分、路由和组件需要懒加载。

2. 基础招数：压缩、Tree Shaking 与副作用标记

2.1 生产模式为何是优化第一刀

如果你的项目还在用 webpack 4 的 mode: 'development' 配置直接打包上线，那不用看别的，先把 mode 改成 'production'，体积立刻能砍一大截。

webpack 的 production 模式会自动开启一系列内置优化：代码压缩、Tree Shaking、作用域提升（Scope Hoisting）、NODE_ENV 自动设为 production（很多库会据此移除开发环境的警告代码）。后端配置改成这样：

javascript复制module.exports = {
  mode: 'production',
  // 其他配置...
};

就这么简单一行，很多项目的包体体积至少能下降 30%。但这不是重点，重点在于后续的深度优化。

2.2 深度压缩：TerserPlugin 与 CssMinimizerPlugin 参数配置

webpack 5 生产模式默认用的压缩器是 terser-webpack-plugin。多数情况下默认配置就够用了，但有些细节如果你不调整，会白白浪费不少体积。

比如默认配置下，Terser 会保留某些注释和 license 信息，这些对运行时毫无意义。可以这样收紧配置：

javascript复制const TerserPlugin = require('terser-webpack-plugin');
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            drop_console: true,
            drop_debugger: true,
          },
          format: {
            comments: false,
          },
        },
        extractComments: false,
        parallel: true,
      }),
      new CssMinimizerPlugin({
        minimizerOptions: {
          preset: ['default', { discardComments: { removeAll: true } }],
        },
      }),
    ],
  },
};

这里说几个配置项的讲究：

• drop_console: true 会把 console.log / console.warn 等调用直接删掉，但注意 console.error 也会被删，建议在线上保留错误日志的，可以单独配 pure_funcs: ['console.log'] 只删 log。
• parallel: true 表示开启多进程并行压缩。在大型项目里，压缩阶段往往是构建耗时的重头，开并行以后构建时间能减少 40% 以上。但这个选项对内存要求比较高，CI 机器内存不够时会 OOM，需要权衡。
• extractComments: false 是说不要把注释提取成单独的 .LICENSE.txt 文件。如果你们的法务或合规要求必须保留部分开源协议信息，这里就不能直接关掉，得用 extractComments 配合正则白名单。
• CSS 压缩也别忘了，很多人只顾得上压缩 JS，结果几个 CSS 文件加起来也有几百 KB。

2.3 Tree Shaking 与 sideEffects：不是自动生效的魔法

Tree Shaking 的原理是借助 ES Module 的静态分析特性，把没有被实际使用的导出代码给“摇”掉。但这里有个大坑：它默认只对 import / export 的 ES Module 生效，CommonJS（require / module.exports）是摇不动的。

我见过不少项目，package.json 里没写 sideEffects 字段或者写错了，导致 Tree Shaking 直接罢工。比如你从 antd 里 import { Button } from 'antd'，如果 antd 的 sideEffects 被标记为 false，webpack 就能大胆地摇掉你没用到的组件样式和 JS；反之如果它被标记为有副作用，webpack 只能保守地全部保留，打包体积当然降不下来。

在你的项目 package.json 里加一行：

json复制{
  "sideEffects": [
    "*.css",
    "*.scss",
    "*.less",
    "./src/polyfills.ts"
  ]
}

意思是告诉 webpack：除了 CSS 和 polyfills，其他模块如果没被引用，都可以安全地移除。这一步配合 production 模式，效果非常明显。

需要注意，如果你在代码里有 import './xxx.css' 这种副作用形式，一定要把 CSS 文件列入 sideEffects 白名单，否则 CSS 文件会被当成本地无副作用模块给摇掉，结果就是线上页面没有样式，而且很难排查。

3. 让代码“按需上路”：路由懒加载与 SplitChunks 分包策略

3.1 路由级动态导入：首屏立减一半

体积优化的第二条主线是“别把所有代码一股脑塞进首屏”。SPA 项目里最常见的问题就是：一个后台管理系统，哪怕用户只登录看个数据大屏，也会把用户管理、订单管理、报表导出等一大坨业务代码全部加载进来。这不合理。

解决方案就是路由级代码分割，按需动态导入。Vue Router 的写法：

javascript复制const routes = [
  {
    path: '/dashboard',
    component: () => import('../views/Dashboard.vue'),
  },
  {
    path: '/user',
    component: () => import('../views/UserManage.vue'),
  },
  // ...
];

React Router 6 的写法类似，用 React.lazy：

javascript复制import { lazy, Suspense } from 'react';

const Dashboard = lazy(() => import('../views/Dashboard'));
const UserManage = lazy(() => import('../views/UserManage'));

function App() {
  return (
    <Suspense fallback={<Loading />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/user" element={<UserManage />} />
      </Routes>
    </Suspense>
  );
}

webpack 遇到 import() 语法或 React.lazy 时，会自动把对应的模块拆成一个单独 chunk，只在用户访问该路由时才加载。

这个优化做完以后，我那个项目的主 bundle 从 4.2MB 直接降到 1.1MB，首屏请求数减少了一半多。这是立竿见影的一招，也是性价比最高的优化手段，强烈建议任何体量超过几个页面的项目都做一遍。

3.2 SplitChunks 分包策略：缓存与体积双赢

按路由拆完 chunk 以后，又会面临新的问题：公共代码被重复打包到了每个路由 chunk 里。比如每个页面都用了 axios，那 axios 会被打进十几个 chunk，每个 chunk 都带一份。这既增大体积，也不利于浏览器缓存。

webpack 5 内置了 splitChunks，默认配置其实已经能处理一部分情况，但要达到最佳效果还是得针对项目定制。我常用的配置方案：

javascript复制module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 20000,
      maxSize: 244000,
      minChunks: 2,
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name(module) {
            const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];
            return `chunk-${packageName.replace('@', '')}`;
          },
          priority: 10,
          chunks: 'all',
        },
        common: {
          name: 'common',
          minChunks: 2,
          priority: 5,
          chunks: 'all',
        },
      },
    },
  },
};

几个关键参数解释一下：

• chunks: 'all' 表示同步加载和异步加载的模块都参与分包。默认是 'async'，如果你不改成 'all'，同步引入的大库根本不会被拆。
• minSize: 20000，只有超过 20KB 的模块才值得单独拆出去。太小了反而增加请求数，得不偿失。
• maxSize: 244000，单个 chunk 尽量控制在 244KB 以内，这是浏览器缓存策略里的常见经验值，超过这个值就尝试继续拆分。
• minChunks: 2，模块被至少 2 个 chunk 引用时才放进公共包，避免为了一个页面单独拆个公共包。
• cacheGroups 里把 node_modules 里的依赖按包名拆分，比如 echarts 单独打成 chunk-echarts.js，lodash 单独打成 chunk-lodash.js。这样某个依赖升级时，浏览器只需要重新下载那一个文件，其他 chunk 的缓存都能命中。

拆包以后的体积对比，我记得特别清楚：优化前 vendor chunk 是 2.3MB，优化后拆分成了 echarts（800KB）、moment（600KB）、react 相关（300KB）等各自独立的 chunk。总加起来仍然不小，但配合后续的按需引入和外部化，又能再压缩一大截。

4. 釜底抽薪：依赖优化与体积连锁反应

4.1 externals 外部化：让 CDN 分担压力

如果你分析了最终的 bundle，发现某个库实在太大（比如 echarts），业务代码里也确实绕不开它，这时候可以考虑 externals。思路很简单：不把它打进 bundle，而是通过 CDN <script> 标签直接引入，运行时从全局变量取对应的库。

webpack 配置：

javascript复制module.exports = {
  externals: {
    echarts: 'echarts',
    react: 'React',
    'react-dom': 'ReactDOM',
  },
};

然后在 HTML 模版里加上 CDN：

html复制<script src="https://cdn.example.com/echarts/5.5.0/echarts.min.js"></script>
<script src="https://cdn.example.com/react/18.2.0/umd/react.production.min.js"></script>
<script src="https://cdn.example.com/react-dom/18.2.0/umd/react-dom.production.min.js"></script>

这里有一个很重要的权衡：外部化以后，包体是变小了，但首屏变成多了一个 CDN 请求，而且如果 CDN 挂了，你的整个应用都会白屏。所以一般只推荐把“体积大、更新频率低、稳定可靠”的库外部化。我自己在实际项目里一般控制外部化数量在 3 个以内，并且选择知名 CDN 服务商或自己公司的静态资源服务器托管。

另外，React 外部化的版本要非常注意，React 16 和 React 18 的 UMD 包结构差异很大，全局变量的挂载方式也不同，别引错了版本导致运行时错误。

4.2 重复依赖与冗余 Polyfill 排查

体积优化里最容易被人忽略的是“同一依赖被打了多份”。我的那个项目里 lodash 被打了两次，就是因为我引用的某个老组件内部依赖了旧版 lodash，而项目顶层依赖了新版 lodash，两套版本并存。npm 的嵌套依赖结构可能会出现多个副本，最终全部被 webpack 打包。

处理方式：

bash复制npm dedupe

它会尽量把嵌套的依赖提升到顶层，消除重复版本。如果 dedupe 解决不了，可以用 package.json 的 resolutions 字段（yarn）或 overrides（npm 8.3+）强制指定某个依赖的版本。

json复制{
  "overrides": {
    "lodash": "^4.17.21"
  }
}

再看 Polyfill。老项目里常会引入 @babel/polyfill 或 core-js 的全量导入，几 MB 的体积就这么堆出来的。现在 babel 推荐按需引入：

json复制{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage",
        "corejs": 3.30
      }
    ]
  ]
}

useBuiltIns: 'usage' 表示只引入代码里用到的 API 对应的 polyfill，比如你用了 Promise 就只补 Promise，用了 Object.assign 就只补 Object.assign。这个配置改完，core-js 的体积通常能减少 70% 以上。

4.3 借力函数库的按需引入方案

lodash 或者 lodash-es 是另一个体积刺客。如果你习惯 import _ from 'lodash'，那整个 lodash（压缩后 70 多 KB）就全进来了。你只是用了个 _.debounce。

正确做法：

javascript复制// 不要
import _ from 'lodash';
_.debounce(fn, 300);

// 应该按方法引入
import debounce from 'lodash/debounce';
// 或者用 lodash-es
import { debounce } from 'lodash-es';

注意，lodash/debounce 这种路径引入方式对 webpack 的 Tree Shaking 比较友好。lodash-es 以 ES Module 形式发布，配合 sideEffects: false 效果更佳。迁移到 lodash-es 的时候要小心，有些模块的路径和 lodash 不太一样，比如 lodash/merge 对应 lodash-es/merge，大体上是能对上的。

组件库同理。antd 从 v4 开始支持按需引入，只要配上 babel-plugin-import 或者直接用 v5 的「tree shaking 友好的 ESM 包」即可。Element Plus 的按需引入则推荐用 unplugin-vue-components 自动导入，不用你手动一个个写 import { ElButton } from 'element-plus'。

5. 图片与静态资源瘦身

5.1 图片压缩与格式升级

很多人以为体积优化只管 JS 和 CSS，图片就不放在心上了。但实际上，一个后台管理系统如果上传了大量截图、富文本里嵌了原图，图片资源占总体积的比例可能高得吓人。

webpack 层面能做的有三件事：

第一，通过 asset 模块的 parser 配置限制内联阈值。webpack 5 把 file-loader / url-loader 统一成了 asset modules：

javascript复制module.exports = {
  module: {
    rules: [
      {
        test: /\.(png|jpe?g|gif|webp|svg)$/,
        type: 'asset',
        parser: {
          dataUrlCondition: {
            maxSize: 4 * 1024, // 4KB 以下转 base64 内联
          },
        },
      },
    ],
  },
};

4KB 以内的小图直接转 base64 内联到代码里，省一个 HTTP 请求。超过 4KB 的走单独文件。

第二，引入 image-webpack-plugin 或 image-minimizer-webpack-plugin 做无损/有损压缩。我的实践是装 image-minimizer-webpack-plugin，配合 imagemin 插件链：

bash复制npm install image-minimizer-webpack-plugin imagemin imagemin-mozjpeg imagemin-pngquant --save-dev

javascript复制const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        minimizer: {
          implementation: ImageMinimizerPlugin.imageminGenerate,
          options: {
            plugins: [
              ['imagemin-mozjpeg', { quality: 75 }],
              ['imagemin-pngquant', { quality: [0.6, 0.8] }],
            ],
          },
        },
      }),
    ],
  },
};

第三，能换的格式尽量换。JPEG 转 WebP，同样视觉质量下体积能缩小 25% 到 35%；如果再激进一点用 AVIF，能再降 20% 左右。不过 WebP 的老浏览器兼容性和 AVIF 的更差兼容性都要提前想好，最好在 <picture> 标签里做格式降级。

5.2 小图片内联与雪碧图取舍

雪碧图（CSS Sprite）在 HTTP/1.1 时代是神兵利器，但到了 HTTP/2 多路复用时代，多个小请求的成本大幅下降，雪碧图的地位就没那么重要了。反而维护成本很高：每次加个图标都得重新拼图、重新算坐标、更新 CSS。

我的建议是：HTTP/2 环境（现在基本默认都是），小图标优先用 iconfont 或 SVG Symbol；内联阈值内的图直接 base64；超过阈值且复用的图再考虑雪碧图，否则单独文件即可。

5.3 字体图标与字体文件子集化

字体是很多人优化时容易忽略的“隐性容量杀手”。一个完整的 fonts/iconfont.ttf 或业务用的中文字体文件，动辄 300 到 800KB。特别是中文网页，中文字体全量字形有数万个，一个字体的 GB 级别都见过。

如果项目里用自定义字体，强烈推荐做子集化，只保留页面实际用到的文字。可以用 font-spider（字蛛）这类工具：

bash复制npm install font-spider -g
font-spider ./dist/**/*.html

字蛛会自动扫 HTML 和 CSS，把没用到的字形全部裁剪掉。对于图标字体也是同理，只保留项目里用到的那几十个图标对应的 unicode 字符，几百 KB 的体积能砍到几十 KB。

6. 优化提速：持久化缓存与构建性能

6.1 持久化缓存 cache 配置

优化体积不能只看最终产物大小，构建速度也必须兼顾。如果每次改一行代码，重新构建要等两三分钟，团队里没人愿意频繁构建，优化方案再牛也不会有落地的积极性。

webpack 5 内置了持久化缓存，只要在配置里开启：

javascript复制module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename],
    },
    cacheDirectory: path.resolve(__dirname, '.temp_cache'),
  },
};

开启以后，二次构建的速度会有飞跃式提升。尤其是大项目，冷构建 120 秒的，开启缓存后二次构建直接降到 20 到 30 秒。持久化缓存的原理是缓存模块的编译结果和依赖关系图，只有文件内容变化时才会重新编译对应模块。

buildDependencies.config 的意思是：当 webpack 配置文件本身变化时，缓存自动失效。这个很重要，别忘了配，不然你改了配置却发现构建结果没变，会怀疑人生。

6.2 moduleId 与 hash 策略：让浏览器缓存更聪明

打包体积优化还要考虑一个维度：浏览器的长效缓存命中率。如果你的打包每次文件名 hash 都在变，用户访问时 CDN 缓存全部失效，又要重新下载所有文件，这跟包体没变小有啥区别？

关键配置是给 module 和 chunk 用稳定的 id 策略。webpack 5 默认生产模式用的是 deterministic，效果已经不错。如果你想更精细地控制：

javascript复制module.exports = {
  optimization: {
    moduleIds: 'deterministic',
    chunkIds: 'deterministic',
  },
};

再配合 output 的 chunkFilename 和 filename：

javascript复制module.exports = {
  output: {
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[name].[contenthash:8].chunk.js',
  },
};

contenthash 是根据内容生成的，内容没变 hash 就不变，浏览器和 CDN 就能长期命中缓存。为了最大程度利用缓存，建议对连续更新的业务代码与不常变化的第三方依赖做分离分包，这正是第 3 节 SplitChunks 分包策略的另一层收益：单独分包以后，你发一次业务代码版本，用户只需要下载业务 chunk，依赖 chunk 全部走缓存。

6.3 按场景关闭 Source Map

Source Map 对开发调试的意义不用多说，但它对打包产物体积和构建速度的影响是实打实的。我见过不少项目，上线版本没关 source map，打包产物里多了一层 .map 文件，有些 .js.map 体积比 .js 本身还大。

推荐的做法是按环境区分：

javascript复制module.exports = (env, argv) => {
  const isProd = argv.mode === 'production';
  return {
    devtool: isProd
      ? false                       // 生产环境不生成 source map
      : 'eval-cheap-module-source-map', // 开发环境快速调试
  };
};

如果你确实需要定位线上问题的 source map，可以只在构建机上生成一次，保存在内部系统里，不直接部署到公网 CDN。这样既避免用户下载 .map 文件拖慢加载，也避免源码直接暴露给最终用户。

前面提到的热搜词 “could not read source map for webpack://meai.web/node_modules/”，就是 source map 使用不当的一种典型报错，下一节我会专门展开讲。

7. 常见问题与排查实录

7.1 TypeError: Could not read source map for webpack://...

前阵子有同事报错：构建时控制台打出 ERROR in Could not read source map for "webpack://meai.web/node_modules/xxx/yyy.js" 类似的警告或报错。很多人在网上搜到一长串讨论，但没人说清楚为什么。

这个报错的本质是：某个库的文件里带了 //# sourceMappingURL=xxx.js.map 的注释，webpack 尝试去读取对应的 source map 文件，但文件不存在或路径对不上（比如发布 npm 包时把 .map 文件漏了，或者换了版本后 .map 指向的路径失效）。

排查和解决步骤：

1. 根据报错路径找到对应的 node_modules 下的包，检查源码末尾有没有 sourceMappingURL。
2. 看看包目录里有没有对应的 .map 文件。没有的话，就是这个包发布不完整，跟你没关系。
3. 根治方法：在 webpack 配置里关掉对该包的 source map 解析，或者直接忽略：

javascript复制module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        enforce: 'pre',
        use: ['source-map-loader'],
        exclude: [/node_modules\/(package-name|another-package)/],
      },
    ],
  },
};

如果项目没有启动 source-map-loader 插件，那可能是库内部依赖触发的。最简单的方式是直接把 devtool 调成不解析外部库 source map 的模式（上文的 eval-cheap-module-source-map 即可），或者在 webpack.config.js 里加上 ignoreWarnings 把这些无关紧要的警告过滤掉：

javascript复制module.exports = {
  ignoreWarnings: [/Failed to parse source map/, /Could not read source map/],
};

这个报错一般不影响产物运行，所以不用太恐慌，按上面的思路处理即可。

7.2 压缩后体积依然很大：先查这 3 个地方

有时候按照上面所有步骤做了优化，压缩配置也开了，分包也做了，最后一看预算，体积还是超。这时候从三个点排查：

1. 检查有没有新增的依赖没有走按需引入。新引入的第三方库可能是体积刺客，比如某个导入了整个 RxJS 的工具库。用 bundle-analyzer 再扫一遍，看哪个矩形突然变大了。
2. 检查有没有在公共 chunk 里混入了只被某个路由用到的代码。公共 chunk 的体积是每个页面都必须加载的，混入低频业务代码会稀释所有页面的首屏性能。
3. 检查有没有把开发环境的调试工具或 devDependencies 的包误打进了产物。比如 mockjs 或 webpack-dev-server 相关的代码被 import 了。注意，import xxx from 'devtools' 这种代码必须使用 import() 动态加载并只在 process.env.NODE_ENV === 'development' 时执行，否则被打包进生产代码就是白费容量。

7.3 动态导入没生效 / 分包不均怎么办

另一个高频问题：代码里写了 import()，但构建完 chunk 数量没有变化，或者所有页面代码又被打回一个 bundle。

常见原因有两个：

1. 你的 webpack 配置里 optimization.splitChunks.chunks 被设成了 'initial' 或者手动覆盖成不合理了。动态导入的 chunk 属于 async 类型，如果 chunks 里没包含 'async' 或 'all'，分包就会异常。
2. 你的 Babel 配置有问题。如果 babel 把 import() 转成了 require，webpack 就无法识别动态导入语法，需要检查 babel 配置里是否设置了过时的 esmodules 转换逻辑。用 @babel/preset-env 时加上 "modules": false，保留 ES Module 语法给 webpack 去做分析。

json复制{
  "presets": [
    ["@babel/preset-env", { "modules": false }]
  ]
}

分包不均的问题一般是 chunk 数量很多但大小分布失衡，比如有个 chunk 700KB，其他都几十 KB。解法是调低 maxSize 或调整 cacheGroups，必要时手动把某些路由的 webpackChunkName 注释写上：

javascript复制const UserManager = () => import(/* webpackChunkName: "user-manage" */ '../views/UserManage');

这样可以给 chunk 起一个稳定的名字，后续在 chunkFilename 的模板里排布也更可控。

7.4 问题排查速查表

7.5 踩坑心得：优化之后必须做的回归验证

优化做完以后，最忌讳的就是直接合代码发版本。打包体积是降下来了，但功能很容易在细节处被“优化没了”。比如 drop_console 把某个依赖内部依赖 console 输出做的怪逻辑打崩了，或者 Tree Shaking 把有副作用的模块给摇没了，再或者 externals 的 CDN 在海外地区加载超时导致某个页面白屏。

我自己总结的回归验证清单：

1. 走一遍核心用户路径：登录、首页、列表、详情、提交表单，看控制台有没有红色报错。
2. 检查页面是否缺少样式。很多 CSS 被 Tree Shaking 的真实案例，就是页面功能正常但没有样式。
3. 用无痕模式刷新确认产品能正常加载，避免 localStorage 缓存给你“假正常”的错觉。
4. 在弱网环境下沙盒测试首屏加载情况，看看 CDN 外部化依赖会不会成为瓶颈。
5. 对比生产环境的 bundle-report 和优化前基线，确认关键体积指标确实下降。

在我实际项目里，优化后的最终结果是这样的：总体积从 4.2MB 降到约 1.0MB，gzip 后从 1.1MB 降到 280KB，首屏加载从 3 秒左右降到 1.2 秒。虽然没有严格达到标题里说的 80%，但这是一个真实业务项目在没有动任何业务功能的前提下拿到的数据。如果你的项目一开始就有良好的编码规范，配合代码分割和按需引入，80% 的目标并不夸张。

最后再分享一个小技巧：把体积优化的效果做成一个脚本，在每次构建完以后自动输出一份体积报告，跟上一次构建对比。我常用 webpack-bundle-analyzer 的 JSON 输出配合一个简单的 Node 脚本，在 CI 上设置阈值卡点，主包体积超过某个值直接失败。这样优化成果不会随着人员流动和需求迭代而“反弹”，打包体积控制才能真正融入到团队的日常开发流程里。