Vite 发布后旧页面动态导入失败，检查旧 chunk 是否还在

网站发布新版本后，已经打开的页面切换路由时报 Failed to fetch dynamically imported module，新开页面却能正常进入。先在浏览器 Network 中找到失败的 JS 地址，再核对它是否属于上一版本的构建文件。

这个报错也可能来自网络、扩展拦截或错误导入路径。只有旧页面仍引用旧文件、发布后旧文件确实不可取得时，才沿着版本不一致这条路径处理；不能仅凭它发生在发布附近就认定原因。

查的是浏览器正在请求的文件

保留失败 URL、状态码、响应内容、页面打开时间和发布版本。带内容哈希的文件名可能随构建变化，某个延迟加载路由在页面初次打开时还没有下载对应 chunk。

例如旧页面引用 /assets/Overview.abc123.js，新构建改为另一个文件名。发布流程若清空旧目录，尚未访问该路由的浏览器之后仍会请求旧地址。入口页面能打开，不代表它将来需要的所有文件仍在。

比较真实发布清单、对象存储或 CDN 中的文件与失败地址。若响应是 HTML，还要确认资源请求是否被 SPA fallback 接走；200 状态并不说明返回了有效 JavaScript。若显示扩展阻止或连接失败，则保留这条证据，不强行解释成旧文件删除。

新开页面与旧标签页应分别检查。仅刷新自己的浏览器可以避开旧引用，不能证明其他长时间打开页面的用户已恢复。

发布时先保证新旧引用有对应文件

优先使用框架或托管平台已有的版本对应方案。自己维护静态发布时，完整上传并验证新版本资源，再切换入口，保留仍可能被旧客户端引用的哈希文件。

保留多久应结合页面实际使用时长、缓存及发布策略决定，没有统一的分钟数能覆盖所有应用。旧资源不能无限堆积，但清理时要有版本和时间记录，避免“每次发布先删整个 assets 目录”成为默认步骤。

入口 HTML 应正确重新验证，例如按适用部署规则设置 Cache-Control: no-cache，并核对 CDN、Service Worker 是否遵守预期。no-cache 允许存储但要求重用前验证，不等于所有内容都禁止缓存。哈希静态资源的长期缓存与入口的更新策略要分别设计。

移除文件名哈希，会把版本冲突转成同名不同内容的缓存问题。给动态 import 随意加查询参数，也不会在服务器上重建已经删除的文件。不要为了避开一次错误，把所有路由改成首屏同步导入，牺牲原本有用的拆分策略。

错误事件用于安排恢复，不会补回 chunk

Vite 4.4.0 的正式实现已提供 vite:preloadError，事件的 payload 保存原始导入错误。使用更早版本时，应先查实际版本是否有该能力，不能把监听器放进去就假定能够收到事件。

监听器须在可能失败的动态导入之前注册。调用 event.preventDefault() 可以阻止该路径继续抛出错误，但不会让缺失模块加载成功，也不保证路由完成；应用仍需明确展示失败状态和恢复入口。

确认是版本变化后，可以提示用户保存内容并重新加载页面。自动恢复若确有必要，必须限制重载次数，并保留再次失败时的提示；入口或 CDN 仍返回旧内容时，无限制 reload 会变成循环。

重载会丢失没有持久化的组件状态。编辑表单、上传和业务提交都要按各自状态处理，不能把所有导入错误转换成无提示刷新，也不能顺手重发可能已经产生结果的写入请求。

发布前保存当前入口、构建资源和缓存配置。验收应保留一份发布前打开的页面，切换版本后访问尚未加载的路由，同时检查新页面、真实缺失资源和重复失败路径。目标是资源与页面引用对应，故障时能安全恢复。回退需要恢复完整版本及它引用的文件，而不是只把 index.html 换回旧文件，却仍让旧 chunk 留在删除状态。