Vite 仍用旧配置

切换分支后，磁盘上的 vite.config.ts 已恢复代理设置，开发服务器却仍把 API 请求返回成 SPA HTML。日志若显示两次配置变化，最后只有一次重启完成，应检查第二次变化是否落在第一次重启尚未结束的窗口内。

Vite 8.2.2 的这条路径会丢掉重启期间的新请求。已核对的正式 8.3.4 会记录待处理重启，并在当前重启后继续处理最新配置。它针对重启合并的时序问题，不解释所有代理或配置不一致。

两次变化，可能只加载了第一份快照

重启不只是关闭端口再监听，还包括读取配置、初始化插件及框架环境。某个配置钩子较慢时，这个阶段可以持续一段时间。

受影响实现发现已经有重启 Promise，就直接返回它，没有记下磁盘配置又变了一次。于是第一次重启完成后，服务器仍使用当时的配置快照；后续文件不再变化，也就没有新的事件让它收敛到当前磁盘内容。

例如日志可能呈现这种关系：

vite.config.ts changed, restarting server...
vite.config.ts changed, restarting server...
server restarted.

日志只能提供时间线。还要对照实际配置差异与响应：API 返回 HTML 也可能是代理匹配、请求路径或目标服务的问题，不能单看响应类型确认这条回归。

让重启完成后再核对实际行为

先确认实际 Vite 版本、正在运行的进程、配置文件路径和分支切换时间，避免访问另一个端口上的旧开发服务器。比较配置里代理或其他选项的最新值，以及服务当前真正使用的行为。

项目兼容时，按现有依赖策略选择带待处理重启机制的正式版本，例如 Vite 8.3.4。该实现会在重启期间标记新的请求，当前一轮完成后继续下一轮；新服务器替换旧对象时，也保留这份重启状态。

暂时不能更新，可以在分支切换和文件写入完成后，停止旧开发进程，再按原入口重新启动。先保存配置差异，保留原有启动参数；不需要为了这次时序故障重写生产代理设置。

反复按重启快捷键，或同时启动多个进程，会让当前配置和监听端口更难辨认。修改配置只是为了再次触发事件，也应确认真正运行的内容，而不是依赖一次偶然恢复。

验收最新配置，而不是最后一条 ready

待全部重启结束后，用项目已有的受控 API 请求检查实际代理目标、响应类型与结果，确认与磁盘上的最新配置一致。涉及身份验证的路径仍保留原认证条件，不能只看一个公开测试页。

随后分别检查单次配置修改与重启期间连续修改的情况，保留相同插件和原有慢初始化条件。只在一个没有插件的小项目里看到一次重启成功，没有覆盖原来的时间窗口。

若 8.3.4 仍不一致，继续核对实际运行版本、配置来源、插件修改和代理规则；不把所有后续问题都归结为这一次已修复的重启队列缺陷。