核心判断
Webpack 的核心范式是构建阶段的预整合：先从入口出发分析完整依赖图，再通过 loader、plugin 和 chunk 机制把模块、样式与资源统一转换为可部署产物。
它的优势来自提前整合：生产产物可控、工程能力完整、生态扩展成熟；它的瓶颈也来自提前整合：开发启动和增量反馈容易被完整依赖图与转换链路拖慢。
这个主题要回答的问题
- Webpack 如何把入口、依赖图、loader、plugin 和 chunk 组织成一条构建流程？
- Webpack 的预整合范式为什么适合生产优化，却容易影响开发反馈？
- Webpack 的代码分割如何在“提前整合”与“运行时按需加载”之间建立过渡？
主题结构
- 入口驱动依赖图：Webpack 从入口文件出发静态分析 import / require，把应用组织成一个可转换、可优化、可输出的模块图。
- loader 扩展可处理资源边界：CSS、图片、字体、TypeScript、JSX 等非标准输入先被转换成 Webpack 能理解的模块，才能进入统一构建管线。
- plugin 扩展构建生命周期：插件化增强构建能力让压缩、拆包、资源分析、产物注入等能力挂接到构建流程的不同阶段。
- chunk 把预整合产物连接到运行时加载：Webpack 仍然预先理解完整依赖图，但可以把部分代码切成异步 chunk，在运行时按需下载。
- 开发体验瓶颈来自完整图谱处理：当项目变大时，启动、重建和 HMR 都可能受到依赖图规模、loader 链路和插件执行成本影响。
相关概念 / 下层卡片
相关入口
- 构建工具演进中的预整合阶段：把 Webpack 放回构建工具处理时机、处理粒度和能力调度方式变化的主线中理解。
- 按需编译范式的对照入口：用 Vite 对照 Webpack，能看清构建工具如何把开发反馈从完整预构建改为请求驱动处理。
暂时结论
Webpack 不是单纯的“打包工具”，而是一种以完整依赖图为中心的构建组织方式。理解 Webpack，要抓住“入口 → 依赖图 → loader 转换 → plugin 增强 → chunk 输出”这条链路如何服务于预整合产物。