构建工具原理与选型

构建工具解决的根本问题是：浏览器认识的东西，和我们写的东西之间有一道鸿沟——模块化、语法降级、资源处理、体积压缩、开发体验（热更新）。

本文只讲模型差异和判断依据，具体配置见 webpack / vite。

一、两代模型的分野

webpack（bundle-based）
  入口 → 递归解析依赖 → 得到一个完整的依赖图 → 打包成 bundle → 交给浏览器

vite（dev: ESM 原生 · prod: rollup）
  开发时：浏览器直接请求 ESM 模块 → 服务端按需编译单个文件返回
  生产时：Rollup 打包（因为生产环境仍需要更少的请求和更小的体积）

关键差异在什么时候做编译：webpack 在启动时把你所有的代码都编译一遍，vite 在浏览器请求到某个文件时才编译它。

为什么 vite 开发启动快

1. 不做全量打包：只预构建依赖（node_modules 里的 CJS/UMD 包用 esbuild 打成 ESM），业务代码零编译启动。
2. 按需编译：改哪个文件编哪个，与项目规模解耦。
3. esbuild 用 Go 写：预构建速度比 JS 实现快一个数量级。

代价：首屏模块请求数变多（几十上百个 ESM 请求）。HTTP/2 多路复用缓解了这个问题，但项目极深时首屏仍可能比 webpack 慢。生产构建 vite 用 Rollup，所以"开发快"不等于"打包快"。

二、webpack 核心机制

概念	作用
entry	依赖图的起点
module / loader	把非 JS 资源（css、图片、ts）转成 webpack 能理解的模块
plugin	在构建生命周期的钩子上做扩展（如 HtmlWebpackPlugin）
chunk	产物分组单位，决定最终生成几个文件
asset	最终写盘的文件

构建流程：初始化参数 → 实例化 Compiler → 执行 run → 从 entry 递归构建模块（make）→ 优化（seal：tree shaking、拆分）→ 输出文件（emit）。

HMR 原理：dev-server 通过 WebSocket 通知浏览器「哪个模块变了」→ 浏览器向服务端请求新的模块 → 用新模块替换旧模块并执行 accept 回调。状态得以保留，是因为只替换了模块而没有刷新页面。

缓存：webpack 5 的 cache: { type: 'filesystem' } 把模块编译结果持久化到磁盘，二次启动只编译变化的模块。

三、Tree shaking 为什么经常不生效

Tree shaking（无用代码消除）依赖静态可分析性，四个前提缺一不可：

1. 必须是 ESM（import/export）。CJS 的 require 是运行时求值，无法静态判定。
2. sideEffects 声明正确。package.json 里 "sideEffects": false 告诉打包器"这个包没有副作用，可以整块删"。如果包里有副作用（如 polyfill、全局样式注入）却声明 false，会被误删。
3. 代码本身无副作用。export const a = init() 这种顶层调用会被保守保留。
4. 生产模式 + 压缩。terser/esbuild 的压缩才能删掉未被引用的声明；开发模式下通常不删，便于调试。