构建产出的资源 url 带查询参数时，vite 8.3.2 修正了对应的 css 预加载行为。这个补丁于 2026 年 10 月 1 日发布，官方记录同时列出向 renderbuilturl 传递查询参数、解析百分号编码的 srcset 地址等修复，核心是定制资源路径时的信息留存与正确解析。
来源：Vite 官方 GitHub 发布记录
其中一类场景是 renderBuiltUrl 返回了带查询参数的地址，另一类则是查询参数需要传入这个地址处理钩子。两者分别出现在钩子的返回与调用边界，不能理解为给所有资源自动追加缓存参数。实际是否受影响，取决于项目有没有用到对应的自定义 URL 处理逻辑，以及最终返回的地址形式。
这个钩子的定位，在 Vite 的 高级公共路径说明里有明确解释：入口 HTML、生成的带哈希资源和原样复制的公共文件，可能被部署到不同位置，单一静态 base 未必能覆盖这种部署关系。experimental.renderBuiltUrl 为这类场景提供构建期定制能力，它不是普通项目必须开启的配置。
官方文档仍将该能力标注为实验功能，还要求传入的文件名以及返回的字符串 URL 采用解码后的形式，由 Vite 在生成地址时处理编码。如果返回运行时代码，相关编码逻辑需要自行处理。8.3.2 的修复并没有取消这些约束，把补丁更新等同于任意编码组合都能自动纠正，这种说法并不准确。
立即学习“前端免费学习笔记（深入）”；
来源：Vite 官方构建文档
HTML 侧的另一项修复，解决了 srcset 里百分号编码 URL 的解析问题。srcset 用于提供多个候选资源地址，和单个普通 src 属性的处理逻辑并不完全相同。发布记录只明确了这一解析修复，没有声称浏览器所有图片选择行为都发生变化，也没有要求把现有静态资源全部改写为新的格式。
与资源定位相关的维护还覆盖了开发与调试场景：打包开发模式开始提供延迟分块的源码映射，Worker 在使用 terser 时的客户端与服务端 URL 得到对齐。前者方便追踪按需加载代码的位置，后者保留了具体压缩器条件，不能据此扩大为所有 Worker 构建路径都存在同一种问题。
性能条目中，官方还列出避免预加载辅助逻辑中的二次复杂度链接扫描，以及跳过中间源码映射编码。这些是实现层面的优化，没有附带统一的构建耗时数据；项目规模、项目依赖和部署方式不同，不能直接把条目换算成固定提速比例。
截至 10 月 27 日，8.3.2 已不是最新补丁，后续还有 8.3.4、8.3.5 等修复记录。对于使用定制资源域名、查询参数或百分号编码文件名的团队，核对重点仍是构建产物的实际 URL、样式预加载结果与部署路径，而不是停留在版本号本身。
