企业官网建设流程全解析

每次接手一个新项目，我第一件事就是拉下代码跑一遍npm run build，看看产物长什么样。用得多了，我就越觉得这事有意思：我们天天在 Webpack 里配置各种 loader 和插件，但很多人其实并不完全清楚，那些 import、require 到最后是怎么变成一串能在浏览器里跑的代码的，更不要说 Tree Shaking 到底在哪个环节起作用、为什么有时候配了也白配。这篇文章我从自己的实际排查经验出发，把 Webpack 的模块打包原理和 Tree Shaking 机制彻底拆开讲一遍，顺带附上我在生产环境里调优配置、排查“摇树失败”的完整记录和踩坑心得，希望能帮你少走一点弯路。

这个概念本身解决的核心问题是：现代前端项目动辄成百上千个模块，如果全都原样扔给浏览器，请求数会爆炸，作用域会互相污染，根本跑不动；而如果只做简单的压缩，又无法识别哪些是真正用到、哪些是没被引用的“死代码”。Webpack 的模块打包，就是把这些零散的模块按依赖关系组织成有限的几个 bundle，Tree Shaking 则是在这个过程中精准剔除无用代码，让产物体积和加载效率都保持在可控范围。这篇文章适合所有用 Webpack 做项目、或者正在优化前端构建体积的开发者，尤其是被“Tree Shaking 为什么没生效”这个问题困扰过的朋友。

1. Webpack 模块打包的核心原理

1.1 从入口文件开始的“依赖图”构建

想弄懂 Webpack，绕不开一个概念：依赖图（Dependency Graph）。我最早看文档时对它没太大感觉，后来自己用 Node.js 写脚本模拟过一遍解析过程，才真正明白这张图是怎么回事。

你可以把 Webpack 想象成一个图书管理员。你的项目里每一份文件都是一本书，入口文件就是书架上摆在最外面那本。管理员从入口书开始，逐页翻看里面引用了哪些别的书，再根据引用信息去书架上找对应书籍，找到后又继续翻那些书的引用……如此反复，直到把整面书架的书都访问过一遍。这个过程中，管理员会在自己的笔记本上画一张“引用网”，也就是依赖图。每本书（模块）在图上都是一个节点，每一条引用关系都是一条边。

在 Webpack 内部，这个过程对应的是编译流程的最前面几个阶段：entry配置告诉它从哪个文件开始，然后解析器会对模块代码做静态分析，把import语句转换成依赖记录，再递归地对每个依赖模块执行同样的解析。这个分析并不需要真正运行你的业务代码，它只关心“这个文件引用了谁”。这也是为什么 Webpack 执行速度受模块数量和依赖链深度影响很大，而和代码具体逻辑复杂度关系不大。

// webpack.config.js 里只需要这样指定入口 module.exports = { entry: './src/main.js', output: { filename: 'bundle.js', path: path.resolve(__dirname, 'dist') } };

你告诉 Webpack “从 main.js 开始”，剩下的梳理依赖、组织模块、生成最终文件，都是它自己干完的。平时我们写多页面应用时也会配置多个入口，其实就是同时让图书管理员从几个不同位置开始翻书，每一条入口对应一棵独立的依赖树，最终可以输出多个 bundle。

1.2 Module、Chunk、Bundle 三者的区别

这三个词如果不弄清楚，很多配置选项都会看不懂。我见过不少人在配置optimization.splitChunks时一头雾水，就是因为没分清它们。

• Module（模块）：你项目里的一个文件，比如src/utils/format.js、node_modules/lodash/index.js。Webpack 里每个文件都会被当成一个模块处理。
• Chunk（代码块）：由若干个模块组合而成的“组”。同一个 chunk 里的模块，是按依赖关系聚合到一起的。它是个中间概念，存在于构建过程里，不等同于最终输出的某个文件。
• Bundle（打包产物）：chunk 经过最终处理和文件写入后生成的产物，是你真正在<script>标签里引用的东西。

简单类比：模块是大米和鸡蛋，chunk 是你把它们装进的一个袋子，bundle 是袋子做完真空压缩、贴上标签后的成品。平时说“第三方库打包到 vendor bundle 里”，意思就是node_modules下那些模块被聚合到某个 chunk，最终输出成vendor.js。

这三个概念还会互相影响。比如你用Dynamic Import（也就是import()）写了一个异步加载的组件，Webpack 就会自动为它单独生成一个 chunk，最后打包出来会多出一个异步 chunk 文件。如果你不懂这个原理，看到构建产物里多出好几个.js文件，会以为是配置出错，其实这是懒加载的正常表现。

1.3 Loader 和 Plugin 在打包链路中的位置

之前有同事问我：Loader 和 Plugin 到底有什么区别？为什么转译代码用的是 Loader，而做包体积分析又要用 Plugin？

我一般这样解释：Loader 是“翻译官”，它负责把 Webpack 理解不了的模块内容，转换成它能理解的 JavaScript 模块格式。比如.vue文件，Webpack 原生完全看不懂，但vue-loader会把模板、脚本、样式拆出来，再分别交给对应的处理程序。.css文件也一样，css-loader会把它解析成 JS 模块，style-loader再把样式以<style>标签的形式注入页面。

Plugin 则是“项目管理者”，它能介入到 Webpack 构建流程的生命周期里，在特定时间节点做额外的事。比如HtmlWebpackPlugin会在构建末尾自动生成 HTML 文件，并把打包产物路径自动写入；MiniCssExtractPlugin会把散落在 JS 里的 CSS 抽离成独立文件；BundleAnalyzerPlugin则在构建完成后生成体积分析报告。

调试构建性能时，我一般会先用speed-measure-webpack-plugin看看每个 loader 和插件到底各花了多少时间，再决定优化优先级。因为绝大多数情况下，编译耗时的瓶颈都在 loader 上，尤其是babel-loader和ts-loader，而 Plugin 往往只是做文件读写，耗时占比相对低。

2. Tree Shaking 是怎么把“死代码”筛掉的

2.1 为什么必须是 ES Module 才能摇树

Tree Shaking 的核心前提是“静态分析”。这句话我反复跟团队强调过，但真正理解的人不多。所谓静态分析，就是不需要执行代码、不依赖运行时结果，纯粹通过看代码结构就能确定模块对外导出了什么、内部又引用了什么。ES Module（也就是import/export语法）的设计天然支持这一点，因为它的导入导出关系在代码编辑完就完全确定了，不依赖任何条件判断或变量赋值。

对比一下 CommonJS 的情况，你会发现它根本无法做可靠的静态分析。看这段代码：

// CommonJS 的模块导出 let api = {}; if (process.env.NODE_ENV === 'production') { api = require('./api.prod.js'); } else { api = require('./api.dev.js'); } module.exports = api;

api的导出内容完全取决于运行时的环境变量，构建工具在不跑代码的情况下没法确定module.exports上到底挂了哪些属性。而 ES Module 的写法是这样的：

import { formatDate } from './utils/date';

formatDate这个名字在源码里就写死了，构建工具可以顺着这句话找到utils/date.js里的对应导出，并判断这个值是否真的被用到。所以 Tree Shaking 只对 ES Module 可靠，这也是为什么很多老库（比如早期版本的 lodash）摇不动树，因为它们发布到 npm 上的版本是 CommonJS 格式的。

2.2 usedExports 标记与 Terser 压缩的“组合拳”

很多人误以为 Tree Shaking 是某个插件单独完成的，其实它是两阶段协作的结果，少了任何一环都不行。

第一阶段是标记阶段，由 Webpack 核心完成。开启optimization.usedExports后，Webpack 会分析每个模块的导出项有没有被其他模块引用，并对“没被引用的导出”做一个标记。直接看标记前和标记后的产物对比，理解起来更直观：

// 原始代码（src/math.js） export function add(a, b) { return a + b; } export function minus(a, b) { return a - b; }

// 经过 usedExports 标记后，并未删除，只是标记了 /* unused harmony export minus */ function add(a, b) { return a + b; } function minus(a, b) { return a - b; }

注意，标记不等于删除。此时minus函数还在，只是有了“我没被使用”的注释标记。真正删除发生在第二个阶段：压缩时由 Terser 之类的压缩器读取这些信息，把标记为未使用的代码从产物中剔除。

第二阶段之所以交给压缩器，是因为“删除无用代码”这件事本质上属于代码变换和死代码消除的范畴，Terser 才是这方面的专家。Webpack 只会说“这段代码可能没用”，Terser 拿到这个提示后才会真正动手删。

所以构建配置里mode: 'production'非常重要，因为它会同时开启usedExports: true和minimize: true，让两阶段机制自动生效。如果你手动把mode改成'none'或者省略了optimization.minimize，那不管你怎么写 ES Module，Tree Shaking 都不会真正工作。

2.3 sideEffects 字段：告诉构建工具“副作用边界”

在开发里我们经常会写“为了生效而导入”的代码，比如全局初始化样式、给原型扩展方法的 polyfill：

import './styles/global.css'; import 'core-js/stable';

这种模块没有导出任何东西，但它执行了操作。如果构建工具看到import './xxx'且xxx没有被使用，直接删掉这段导入，那样式就丢了、polyfill 就没了，页面直接报错。为了区分这种情况，package.json 里的sideEffects字段就成了关键。

• "sideEffects": false表示当前包的所有模块都无副作用，可以放心删除未使用导出对应的模块代码。
• "sideEffects": ["*.css", "./src/polyfill.js"]则声明只有这些匹配的文件有副作用，其他无副作用的文件都可以参与摇树。

如果某个二方包或者我们自己的项目里配置了sideEffects: false，但实际却有纯副作用导入的模块，摇树之后就会出现“页面样式丢失”“全局变量没挂上”这类诡异问题。这个字段一定要跟实际代码情况严格对齐，宁可一开始写精确的匹配列表，也不要图省事一禁了之。

2.4 Babel 转译对 ES Module 的“隐形破坏”

这个坑我在刚接触 Webpack 配置时踩过一次，而且很难排查。当时项目的构建配置里用了@babel/preset-env，它的默认行为会顺手把代码里的 ES Module 转成 CommonJS（require/module.exports）。一旦模块变成了 CommonJS，Webpack 的静态分析能力就抓瞎了，Tree Shaking 直接失效。

@babel/preset-env提供了一个配置：

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

modules: false告诉 Babel 不要动import/export，把模块语法原样保留，让 Webpack 自己去做模块解析和摇树工作。如果你的代码是通过.babelrc或babel.config.js配置的，一定要确认这个字段。

另外，如果你用的是 TypeScript，tsconfig.json里module字段不能设置成CommonJS，得保持 ES Next 或者 ES2015+，否则编译出来的 JS 同样是 CommonJS 格式，摇树就失效了。我见过一个项目 TS 配置里写了"module": "CommonJS"，结果构建产物比预期大了 30%，一查就是这个原因。

3. 实操：从零配置一套可摇树的 Webpack 构建

3.1 基础配置：entry、output、mode 与 optimization

先给出一份我在实际生产项目中使用的、相对精简但完整的 Webpack 配置文件，我拆开讲每一段的用途。为了贴合大家最常用的 Webpack 5 场景，我以它为例：

// webpack.config.js const path = require('path'); const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer'); module.exports = { entry: './src/main.js', output: { filename: '[name].[contenthash:8].js', path: path.resolve(__dirname, 'dist'), clean: true }, mode: 'production', devtool: 'source-map', module: { rules: [ { test: /\.js$/, exclude: /node_modules/, use: { loader: 'babel-loader' } } ] }, optimization: { usedExports: true, minimize: true, splitChunks: { chunks: 'all', cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: 'vendors', priority: 10 } } } } };

mode: 'production'做的事情远超大部分人想象。它不只是设置process.env.NODE_ENV，还自动开启了usedExports: true、minimize: true、sideEffects: true（这里的true表示启用 sideEffects 字段判定）等多个优化项。你可以把它理解为“一键进入生产模式”的开关，省去手写一堆 optimization 选项的麻烦。

不过从可复现性角度，我还是建议把关键优化项显式写出来。之前有同事从别的项目拷了一份配置，那个项目设置了mode: 'none'，但为了开发时不受压缩干扰，结果发到测试环境才发现体积暴涨。如果你能理解每个开关的意义，就不至于被这种“隐藏默认值”坑。

3.2 校验 Tree Shaking 是否生效的三个步骤

配置写完了，怎么确认它真的生效了？我常用的办法分三步，每一步都不需要额外装太多东西。

第一步：先找工具库写个测试用例。比如在本地建一个src/utils/math.js，里面导出两个函数，但只在一个文件里导入其中一个：

export function add(a, b) { return a + b; } export function multiply(a, b) { console.log('I am expensive!'); return a * b; }

然后在入口文件里import { add } from './utils/math'。打包完成后直接搜索产物，如果还能搜到I am expensive!这一段字符串，说明摇树没有生效。

第二步：看压缩代码的搜索难度。压缩后的代码可能把字符串做了各种编码或转换，直接搜索不一定可靠，所以我更倾向于开一个 source map，然后用浏览器 DevTools 的 Sources 面板搜索，或者直接不压缩一次，查看中间产物。

第三步：也是最省事的一步，装webpack-bundle-analyzer，它生成的 HTML 报告会直接展示每个模块打包进哪个 chunk、体积多大、哪个文件占了大头。Tree Shaking 成功后，那些“从未被引入却出现在产物里”的模块会在报告里明显减少。

3.3 针对 l刃ndash 这类老包的“换血”策略

在实战中你会发现一个非常气人的现象：项目的业务代码写得规规矩矩，ES Module 语法齐全，但最终产物体积还是大得离谱。打开体积分析报告一看，lodash占了 70 多 KB，而且大部分函数都没用到。

原因是 npm 上很多老版本的lodash主入口文件是lodash.js（CommonJS 格式）。你写import lodash from 'lodash'，本质上是把整本字典都搬进了代码。解决方案最粗暴但最有效的是改造导入路径，换成按模块引入的子路径：

import cloneDeep from 'lodash/cloneDeep'; import throttle from 'lodash/throttle';

这样 Webpack 只加载cloneDeep.js和throttle.js这两个文件，不会把整个字典打进去。如果你的同事或团队更偏好统一风格，还有一个替代方案是安装lodash-es，它保留了 ES Module 格式的代码，配合sideEffects: false可以做到更好的摇树。

最好别在业务代码里直接用lodash.xxx这种单模块 npm 包，因为版本维护和类型定义都容易出问题。我一般默认是：老包先看有没有-es版本或者官方 ESM 版本，没有的话再走子路径导入的路子。

3.4 注意新版 Webpack 5 的特性变化

Webpack 5 上线已经很久了，但很多项目还在用 Webpack 4 的配置习惯。这里有一个和 Tree Shaking 直接相关的点：Webpack 5 对嵌套的 tree-shaking 支持更彻底，比如某个模块内部只有一小段函数被使用，这个函数依赖的局部变量和子函数都能被递归分析并摇掉。Webpack 4 偶尔会有“摇不干净”的情况，升级到 5 之后产物体积能再小一圈。

升级最大影响其实是配置项的命名和默认行为变化。optimization相关选项大部分默认值都更智能了，以前需要手工开的一些开关在 Webpack 5 里是默认开启的。从 4 升到 5 时，我建议直接对照官方迁移指南逐项检查，千万不要图省事直接拿旧配置跑，很容易出现 silent 的构建行为变化。

4. 常见问题与排查技巧实录

4.1 我踩过的那些“Tree Shaking 失效”案例

整理一下我在真实项目里碰到过的场景，有些至今记忆犹新。

第一个案例：样式丢失。某次升级依赖版本后，测试同学反馈“弹窗的遮罩层样式没了”。查了很久，最后发现是某个模块的 package.json 里有"sideEffects": false，但模块内部却import './modal.css'。webpack 判定这个模块无副作用，顺手把整个模块的代码（包括那条 CSS import）都删掉了。解决方式是把sideEffects改成["*.css"]，明确告诉构建工具“CSS 文件是有副作用的，别删”。

第二个案例：全局变量挂载失效。项目里有一段给window挂共享方法的代码：

import './global-setup';

而global-setup.js里确实执行了window.myPlugin = ...。如果 package.json 写了sideEffects: false，这段导入也可能被干掉。这个问题的排查难点在于：删除后运行时不报错，只是默默少了一个全局方法，往往要到某个深层功能被点击时才出现异常。

第三个案例：@babel/preset-env的默认转换。前面已经说过，这里再补充一个判断技巧。打包完成后打开产物文件搜exports.或module.exports，如果搜到了，说明代码里还存在 CommonJS 格式痕迹，ES Module 很可能已经被动过手脚。

我把这些常见失效原因整理成一张速查表：

4.2 如何利用构建日志和产物内容反向定位

遇到问题先不急着改配置，打开构建日志看看 Webpack 自己说了什么，往往能省下一半时间。开启 stats 详细输出：

module.exports = { stats: { modules: true, reasons: true, usedExports: true } };

reasons: true会展示每个模块是因为谁被引用的（reasons 列表），这能帮你判断某个模块到底是不是真的没被入口引用。usedExports: true则直接显示每个模块里哪些导出被使用了，哪些被标记成 unused。

我还会配合webpack-cli的--json参数，把完整构建信息输出成 JSON 文件，再用 Node 脚本快速分析某些关键指标（比如 chunk 数量、每个 chunk 的模块列表）。文件大了之后，肉眼已经看不过来了，脚本才是朋友。

npx webpack --json > build-stats.json

拿到这个 JSON 文件后，可以写个简单脚本查一查“哪些模块被标记为 unused exports 的占比最高”。这通常就是摇树空间最大的地方。我一般会把这些模块按体积排个序，优先处理最大的那批。

4.3 一个容易被忽略的细节：压缩器版本与注释保留

Tree Shaking 的最终删除是压缩器干的，压缩器的配置直接影响摇树效果。尤其是terser-webpack-plugin，它在 Webpack 5 中是默认压缩器。有一个常见需求是“生产环境保留版权注释”，这跟摇树就有冲突风险。

如果你在压缩器配置里写了extractComments: true，Terser 会把抽取到的@license、@preserve等注释单独存到一个.txt文件里，而不是全部丢弃。这个机制本身不碍事，但如果你在minimizer里自定义了 Terser 实例，却忘了加上parallel参数，多进程压缩可能被关掉，构建速度会明显变慢。

const TerserPlugin = require('terser-webpack-plugin'); module.exports = { optimization: { minimize: true, minimizer: [ new TerserPlugin({ parallel: true, terserOptions: { compress: { drop_console: true } } }) ] } };

drop_console: true是我在生产环境的常规操作，能把console.log直接丢掉，顺带对体积有微小帮助。这里有个取舍要注意：线上需要排查问题时，如果 console 全被删了，会失去一些日志线索。我一般通过环境变量来控制是否开启这个选项，开发环境保留，生产环境裁剪。

4.4 业务代码层面配合 Tree Shaking 的写法建议

框架选型、组件库选型对摇树的影响也不小。比如 antd 这种组件库，它提供的是 ES Module 构建产物和按需加载方案，配合babel-plugin-import或直接使用其.esm入口，效果很好。如果你的项目还在用老版本的组件库，且没有按需引入，构建体积会显著偏大。

业务代码侧我总结了几条原则：

• 尽量用具名导入，避免import * as utils导入整个命名空间。因为命名空间对象一旦整体被引用，这个对象上的所有属性都可能被保留，摇树空间大打折扣。
• 写文件时不要让一个模块承载太多导出。比如一个utils.js里有 30 个函数，但某段业务只需要 2 个，除非摇树彻底生效，否则打包器要分析的东西也会更多。按业务域拆分成多个小文件，摇树效率和可维护性都更好。
• 避免使用动态的模块访问方式，比如obj[key]这种路径。如果代码写成import * as utils from './utils'再utils[name]()，构建工具无法静态判断name是多少，只能保守地把utils里所有导出都保留。
• 对于组件库，尽量使用已提供 ESM 入口的版本。我在改造项目时把antd和lodash这两个大头优化了一下，产物体积直接少了近三分之一。

这样看起来似乎改动工程很大，但多数场景只是把导入写法规范化，收益非常可观。

5. 构建体积优化的组合玩法

5.1 从 Tree Shaking 延伸出去的几个配置联动

Tree Shaking 不是孤立存在的，它和代码分割、持久化缓存、压缩策略等机制经常要搭配使用。实际优化时，我一般按这样一个顺序来调整：先保证 Tree Shaking 彻底生效，再做代码分割，最后考虑压缩和缓存策略。

顺序很重要。如果你先做了代码分割，但 Tree Shaking 没生效，那每个 chunk 里都会混入一堆无用的第三方代码，后续再去拆就显得很别扭。=先摇树，再分块，才能看清楚每个业务模块的真实体积。

代码分割的典型配置是splitChunks，我把第三方依赖统一抽到一个 vendor chunk 里，再利用contenthash实现长效缓存。这样业务代码更新时，vendor 文件的 hash 不会变，用户浏览器里缓存住的公共库文件就不需要再次下载。

optimization: { splitChunks: { chunks: 'all', cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: 'vendors', priority: 20 }, common: { minChunks: 2, name: 'common', priority: 10 } } } }

minChunks: 2的意思是：如果一个模块被两个及以上的 chunk 引用，就把它抽到 common 里。这个配置能有效减少多个业务 chunk 之间的重复代码，配合摇树一起用，效果会更明显。

5.2 Module Federation 和 Tree Shaking 的关系

如果项目是微前端架构，大概率已经接触过 Webpack 5 的 Module Federation。它允许不同应用之间共享代码，运行时的共享机制和 Tree Shaking 并不完全冲突，但确实存在一些注意点。

共享模块是通过运行时容器（runtime container）动态加载的，打包器无法在构建期对“别的应用会用到这个共享模块的哪个导出”做静态分析。所以共享模块通常会被完整打包，摇树对它很难起效。我当时在团队里落地 Module Federation 时，做了个简单规定：必须共享的代码尽量拆小粒度，最好共享一个只包含少量 API 的独立子包，而不是直接把整个组件库挂到 shared 上。要是只共享用到的那几个函数，共享包的体积会小很多，各个应用的构建速度也更快。

5.3 性能取舍：摇树对构建耗时的影响

膨胀的模块数量会拖慢构建速度，Tree Shaking 的静态分析同样有成本。实际跑大型项目时，开启usedExports和sideEffects的分析会增加一些编译时间，压缩阶段因为要执行死代码移除，耗时也更高。但和构建产物体积带来的收益相比，这点耗时几乎可以忽略。

真正需要警惕的是压缩阶段的耗时。terser-webpack-plugin的parallel默认是开启的，它可以根据 CPU 核数并行压缩多个 chunk。如果你手动配置了minimizer，务必保留parallel: true，否则生产构建时间可能翻倍。我在一台 8 核 16 线程的 Mac 上实测过，一个 300 多个模块的项目，开启并行压缩，生产构建从 45 秒缩到 21 秒，效果显著。

另外一个常用组合是cache: { type: 'filesystem' }，这能启用 Webpack 5 的持久化缓存。第一次构建时生成缓存，之后只有变更过的模块才会重新编译。配合 Tree Shaking 这种计算密集的分析，二次构建速度能提升 50% 以上，非常推荐在生产流水线里打开。

5.4 用一个真实示例演示配置前后的体积变化

我拿一个内部项目举例，这个项目包含 React、antd、lodash、axios 等常见依赖，业务代码大概 200 个模块。最初配置是mode: 'development'，直接打包出来的 dist 体积让我当场心凉。

随后我做了四步调整：

1. 把mode切到production，同时显式设置usedExports: true，让 Tree Shaking 进入正式工作状态。
2. 把@babel/preset-env的modules设为false，避免 ESM 被改写成 CommonJS。
3. 在 package.json 里补上sideEffects: ["*.css"]，CSS 文件保留，其余代码参与摇树。
4. 引入terser-webpack-plugin，开启并行压缩和drop_console。

打包完成后，主 bundle 从调整前的 912 KB 降到了 563 KB，gzip 之后大约省了 120 KB。这还是在 antd 按需引入和 React 没有完全摇树的情况下。如果把 antd 的 ESM 入口和lodash-es也换上，最终体积可以压到 430 KB 左右，整体优化幅度接近 53%。

这个例子让我充分认识到：Tree Shaking 生效与否，不仅仅是“有没有删掉几个函数”的问题，它直接影响整个应用的加载性能、边缘缓存命中和用户体验。没有沉淀优化经验的项目，往往就是在这种细微的地方被拉开差距的。

6. 调试工具与排查技巧的快速参考

6.1 必装工具清单

我强烈建议团队里统一安装以下几个工具，排查构建问题时会省很多事：

• webpack-bundle-analyzer：可视化分析打包产物，看每个模块占多大体积。
• speed-measure-webpack-plugin：用于定位 Webpack 构建流程中耗时最长的环节。
• webpack-cli的--json输出：导出完整构建统计信息。
• terser-webpack-plugin：自定义压缩行为，控制摇树的最终执行。

这些工具在正常项目里直接作为 devDependencies 安装即可。它们本身不会对构建结果产生影响，只在调试时输出信息或修改压缩行为，用完后从配置里去掉就行。

6.2 常用的构建分析命令整理

和具体的构建工具链一样，我积累了一套自己的固定操作流程：

# 查看构建基本信息 npx webpack --mode production # 将构建信息导出为 JSON，便于脚本分析 npx webpack --json > stats.json # 直接启动体积分析 npx webpack --mode production --profile --json > stats.json npx webpack-bundle-analyzer stats.json

配合脚本分析 stats.json 时，我通常会关注三个核心指标：模块总数、被标记未使用的模块数量、每个 chunk 的初始大小。模块数量多但未使用标记多，意味着摇树没有全都生效；chunk 初始大小偏大，需要检查是否有大依赖被整包引入。

6.3 快速判断 Tree Shaking 是否生效的检查清单

最后分享一份我每次做构建优化都要过一遍的检查清单，你可以照着操作：

1. 确认所有业务代码使用 ES Module 语法，项目中不存在旧版 CommonJS 风格文件。
2. 确认mode: 'production'或手动开启optimization.usedExports和minimize。
3. 检查 Babel 配置，确认modules: false。
4. 检查 TypeScript 配置，确认module是 ES Next 而不是 CommonJS。
5. 检查所有入口依赖的 package.json 的sideEffects字段是否精确。
6. 针对第三方库，优先选择提供 ES Module 版本的包。
7. 通过产物搜索和webpack-bundle-analyzer验证未使用代码是否已被删除。

按这套流程排查过一轮之后，大部分 Tree Shaking 失效问题都能很快定位。剩下的无非是少数特殊场景，但原理吃透了，触类旁通并不难。

我自己平时有一个习惯，就是每次构建完必看一眼产物中最大那几个文件。如果发现某个模块的体积异常，我会用webpack-bundle-analyzer点开看它内部到底包含什么，再决定是优化导入路径、替换库还是调整 splitChunks。构建配置这东西，与其看十篇文章，不如亲手打开一次产物，看着那些数字变化来得实在。