Vite 在 macOS 反复处理根目录外文件，监听不断增长

macOS 上的 Vite 开发服务越用越慢，反复访问或热更新同一份工作区外文件后，监听注册持续增加；普通 root 内文件没有相同趋势。此时应检查额外文件监听是否反复走了 FSEvents 的注册路径。

Vite 8.3.5 配合 chokidar 3.6.0 有这条具体表现。它限定 macOS 的 FSEvents 后端与 root 外文件，不能只凭内存上涨就归为这条问题，也不能把它写成 Linux 的 inotify 配额不足。

同一个文件可能被多次 add

Vite 在转换过程中会确认某些文件受到监听。正式 8.3.5 的 ensureWatchedFile() 对存在且位于 root 外的文件调用 watcher.add；同一个文件再次转换，也会再进入这条路径。

相关 FSEvents 注册路径没有在这些重复调用中完成预期的去重，于是相同文件可能不断增加底层监听关系。应记录触发文件的真实路径、它与 root 的关系、实际 Vite/chokidar 版本和当前后端。不要只从 watcher 输出的一份路径列表判断底层注册必定只有一个。

软链接、monorepo 共享包和插件返回的真实文件都可能位于 root 外。这里的“外部”是开发项目根目录关系，不是说文件来自互联网，也不意味着应扩大服务器可访问的目录范围。

临时切换后端时写清轮询选项

可在现有开发配置中停用 FSEvents，并明确是否允许轮询。例如希望采用普通文件系统事件时，配置片段是：

server: {
  watch: {
    useFsEvents: false,
    usePolling: false,
  },
},

Vite 将这类选项传给 chokidar。chokidar 3.6.0 在 macOS 关闭 FSEvents 后，轮询默认值会随之变化，因此不要只写一个开关，就假定资源成本和后端没有其他改变。

普通事件后端不适合某些网络盘或虚拟文件系统时，可能仍需按实际条件使用轮询，但要评估扫描频率和资源开销。不要为了避开重复注册而把整个 watcher 设为 null，那会失去正常变更通知；也不要关闭外部目录的访问限制来试图修监听。

修改后停止旧开发服务，再按原入口重启。刷新浏览器不会清除旧服务进程里已经累积的监听。原配置应保留，以便不同文件系统环境需要恢复时逐项回退。

同一文件多轮修改后再检查

保留原来会反复触发转换的 root 外文件，重复修改并访问，确认监听资源不再随每轮持续累积，开发服务仍能及时响应。再检查文件删除后重建、root 内文件变化，以及实际热更新功能。

仅看到内存暂时降低，或禁掉相关页面后不再增长，都没有验证原有监听需求仍可用。该配置仅规避这条监听后端路径；其他 watcher 故障仍应按实际文件系统和监听证据处理。