Vite 为什么开发阶段不用打包：原生 ESM 与热更新的边界在哪

Vite 的核心洞见只有一句话：现代浏览器已经原生理解 ES 模块，那开发阶段为什么还要打包。这句话听起来简单，但它改变了前端开发的整个反馈循环。

开发阶段发生了什么

开发服务器把源文件以原生 ES 模块的形式直接发给浏览器，浏览器按 import 语句按需请求。你打开首页，它只加载首页需要的模块，没点到的路由一行代码都不下载。依赖项比如 React 本身会用 esbuild 预打包一次并缓存，esbuild 用 Go 写，速度比 JS 实现的打包器快一个量级。结果是几十万行的项目，开发服务器启动也在秒级以内。

HMR 的真实价值不是快

热模块替换的价值在于保状态。改一个组件的样式，页面立刻更新；改组件逻辑，它在保留当前 state 的情况下替换掉。对比过去保存、等待重构建、刷新、重新填一遍测试数据的循环，省下的不是几秒钟，是注意力的连续性。调试一个复杂表单时这一点尤其明显。

生产阶段仍然打包

浏览器逐个请求几百个模块在生产环境是灾难，所以构建仍然走 Rollup。开发优化反馈速度，生产优化交付速度，一个工具分两个模式承担两件事，这是设计上的取舍而不是妥协。

边界在哪

依赖预打包对 CommonJS 包的兼容需要插件兜底；某些动态 import 的路径在开发与生产表现不一致；大型 monorepo 里源码链接多的时候冷启动还是会慢。知道这些边界，出问题时才不会怀疑人生。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

原生 ESM 那套说法对，但边界要补一句：依赖预打包对 CommonJS 的兼容还得靠插件兜底，monorepo 里源码链接多的时候冷启动照样慢。真出问题通常不是原理错了，是这几个边角。

原生 ESM 的好处不只是快，是请求边界跟模块边界对齐了，出问题一眼能定位到具体文件。代价我踩过：首屏几百个模块请求，HTTP/2 下还行，遇到 HTTP/1.1 或者公司内网代理限并发就直接废掉。所以生产构建这一步还是省不掉，开发体验和部署安全要分开两个维度看。