Vite 8.3.5 一半的修复在 bundled-dev：把 dev 也打包这条路还在补课

Vite 8.3.5 是 10 月 21 日的补丁版，21 条修复。打开清单第一眼看到的是分布：8 条挂在 bundled-dev 前缀下，2 条是 build 里的 chunk import map，其余散在 CSS、依赖升级和各平台细节上。同日还发了 6.x 线的 6.4.5。

bundled-dev 是什么，为什么它占了近一半

bundled-dev 是 Vite 8 引入的开发模式：dev 阶段也走打包，而不是像传统 dev server 那样按请求逐个模块转译。动机很直接 —— 模块图很大的项目（几千个模块），浏览器要发几千个请求，冷启动慢得离谱；先打包再送，请求数掉到个位数。

代价是：一旦 dev 和 build 共享同一条打包管线，所有「只在 dev 出现」的语义都得重新实现一遍。8.3.5 修的这 8 条，全都是这类语义：

修复	说明
停止在「已不再被导入」的模块上传播 HMR	删掉 import 之后，改动仍会触发更新，页面刷得像抽风
转发错误栈经过 bundle 的 source map	不映射的话，dev 里的报错行号全落在打包产物上
把 server.origin 应用到资源 URL	反代 / 自定义 origin 下资源 404
fallback 页面声明 utf-8	找不到路由时的兜底页中文乱码
忽略 build.chunkImportMap	构建专用配置漏进 dev
用户自定义的 import.meta.env.* 进入 env 对象	自定义变量在 dev 里读不到
规范化被服务的输出文件	路径归一化
其余细节	——

这张表读下来像什么？像一个「把 dev 当成 build 来跑」的方案在补齐 dev 该有的体验。HMR 的传播边界、错误栈的可读性、自定义 env 的可见性 —— 这些在传统 dev server 里是天然成立的，因为它们各自有独立的实现路径；一旦合并，就得一条条补。

我的看法是：这条路方向没错（冷启动与请求数是真痛点），但它把一个「稳定的开发体验」重新变成了需要持续修的东西。用 8.x 的项目要习惯这种节奏：每个补丁版都有几条 bundled-dev。

chunk import map：构建正确性，不是体验

两条 build 修复值得单独说：

• 处理缺失的 chunk import map（#23777）：产物里某些 chunk 引用了不存在的 import map 条目。
• 把 preload 依赖算进 chunk import map 的哈希（#23793）：哈希只算了 chunk 本身，没算它预加载的依赖 —— 结果依赖变了但文件名没变，浏览器拿着旧缓存去加载新代码。

第二条是典型的缓存键设计错误：哈希函数的输入漏了一项，输出看起来正常，问题只在「依赖变更但 chunk 未变更」的组合下出现。这类 bug 极难在测试里覆盖，因为它需要一个特定的变更顺序。

CSS 里一个百分号

还有一条看起来很不起眼：url() 里的字面 % 不再导致失败。

/* 这类写法在旧版本会让构建报错 */
.hero {
  background-image: url('/img/100%25-banner.png');
}

URL 里的 % 是百分号编码的引导符，必须是 %25 才合法；但解析器如果先做 URL 解码再判断，就会把 %25 解成 % 然后判定非法。这是「解码与校验的顺序」问题 —— 和我们上周在 Node 的 tls/dns 修复里看到的是同一类错误，只不过那边是安全问题，这边是构建失败。

升不升

升。补丁版，21 条里没有一条会改 API，而 chunk import map 那两条是产物正确性问题 —— 哈希算错意味着线上可能拿到不匹配的代码，这种 bug 表现为「某个用户的白屏，刷新就好」，几乎不可能靠报告定位。

要留意的是：如果你的项目开着 bundled-dev，升级后建议清一次 node_modules/.vite 再起 dev。这类缓存对打包管线的假设很敏感，跨版本留着容易出「改了代码没反应」的假象。

顺带说一句 6.x：同一天发的 6.4.5 说明 6 线还在维护。项目如果卡在 6，别急着跨大版本 —— 8 的收益主要在 bundled-dev 与 rolldown 管线，如果你的构建时间不是痛点，没有必须付的迁移成本。