⚡ 30 秒速记

• 核心判断：构建工具从入口解析依赖图，经转换和优化生成可在目标运行时加载的模块与资源
• 原理主线：围绕 「All in One 的弊端」、「Code Splitting」、「写在最后」 建立输入、状态变化与输出之间的因果关系
• 文章范围：介绍了 Webpack 的 Code Splitting（代码分割）原理及其在大型前端应用中的应用，分析了 All in One 打包方式的弊端，并讲解了如何通过多入口和动态导入实现按需加载与优化性能，帮助开发者高效拆分和管理复杂项目的打包
• 边界与代价：静态分析受模块语法、动态依赖和副作用声明限制；拆包过细也会增加请求和运行时成本
• 工程落地：优化前先测构建阶段、产物组成和缓存命中，再针对解析、转换、压缩或运行时逐层处理

复杂应用应通过多入口和动态 import() 做代码拆分，让启动阶段只加载当前真正需要的资源。 多入口更适合多页应用，每个页面对应一个入口，再用 splitChunks 提取公共模块，避免重复打包。单页应用通常按路由或功能动态导入，Webpack 会把相关模块拆成独立 chunk，运行到对应逻辑时再加载。拆包也不是越细越好，请求开销与公共缓存都要考虑；需要稳定命名时可使用 webpackChunkName 魔法注释。

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 旧文中的 webpack 4、JSONP 更新清单或 react-hot-loader 代码用于解释历史链路，不应直接复制到新项目。当前 webpack-dev-server 4+ 默认启用 HMR，严格 ESM 可使用 import.meta.webpackHot；生产环境不得携带 HMR runtime。以 webpack HMR 官方指南 和项目锁定版本为准。

All in One 的弊端

通过 Webpack 实现前端项目整体模块化的优势固然明显，但是它也会存在一些弊端：它最终会将我们所有的代码打包到一起。试想一下，如果我们的应用非常复杂，模块非常多，那么这种 All in One 的方式就会导致打包的结果过大，甚至超过 4 ～ 5M。

在绝大多数的情况下，应用刚开始工作时，并不是所有的模块都是必需的。如果这些模块全部被打包到一起，即便应用只需要一两个模块工作，也必须先把 bundle.js 整体加载进来，而且前端应用一般都是运行在浏览器端，这也就意味着应用的响应速度会受到影响，也会浪费大量的流量和带宽。

所以这种 All in One 的方式并不合理，更为合理的方案是把打包的结果按照一定的规则分离到多个 bundle 中，然后根据应用的运行需要按需加载。这样就可以降低启动成本，提高响应速度。