Vite 监听文件报 EBUSY

后端刚完成一次编译，vite dev 就退出。错误指向的不是前端源码，而是项目根目录下的 DLL：

Error: EBUSY: resource busy or locked, watch '.../Release/Some.Entities.dll'
Emitted 'error' event on FSWatcher instance
syscall: 'watch', code: 'EBUSY'

这段错误需要分两步看：文件暂时无法监听，是文件系统返回的失败；失败进一步变成未捕获异常、终止 Vite，则涉及开发服务器是否处理了 watcher 的 error 事件。只处理占用文件，不一定能补上后一处缺口。

没被前端导入，也可能被监听

普通开发模式的 Vite 会监听项目根目录。前后端放在同一个目录树里时，后端生成的 bin 输出也可能进入监听范围，不能因为 DLL 没有被 JavaScript 导入，就认为它不会触发 watcher。

已确认的环境包含 Windows 11、Node 24.21.0，以及 Vite 8.3.0、7.3.1 和 7.1.9。Windows 编译器刚写完程序集、仍持有文件句柄时，监听新文件可能报 EBUSY。这个真实锁文件触发条件与 Node、libuv 版本有关；它不能代表所有平台都会锁住同类文件。

缺少错误监听器则是另一层问题。旧 Vite 的 watcher 已处理文件新增、变化和删除，却没有接住 error。Node 的 EventEmitter 遇到没有监听器的 error 事件会抛出异常。因而，换成另一种监听失败，也可能走到同样的退出路径。

先从已有日志核对 syscall: watch、失败路径和 FSWatcher 堆栈。如果错误来自 DLL 构建工具本身、模块加载或端口监听，就不属于这里的 watcher 分支。也不需要主动制造锁文件或手动发送错误事件来排查线上开发环境。

接住错误之后，还要处理监听范围

已核对的正式版 Vite 8.3.4 注册了 watcher 的 error 监听器，把错误交给日志记录，不再仅因这个无人接收的事件退出。这只能确认该正式版本含有处理逻辑，不能据此指定所有发行线的首个修复补丁。

升级应沿项目允许的兼容路径进行，保留现有框架插件和构建配置。无法直接迁移到这个版本时，先检查所用发行线的实现，不要在应用入口加一个全局 uncaughtException 处理器来吞掉错误；它会把其他不能安全继续的异常一起掩盖。

如果 DLL 所在的生成目录确实与前端开发无关，可以在现有 server.watch.ignored 中增加针对该目录的规则。规则按 Vite 实际 root 和目录布局确定，并保留已有的 ignored 配置。不要忽略整个项目、全部源码或所有出现错误的路径。

某些项目会从后端输出目录复制静态资源，或者需要监听其中的文件。这时不能直接排除该目录，应先调整输出位置、共享文件的时机或文件权限，让需要的内容仍能被监听。日志不再导致进程退出，并不等于无法监听的文件已经恢复覆盖。

验收进程与真正的源码更新

在受控的开发环境中重复原来的编译操作，确认 watcher 失败会留下明确日志，Vite 不再以未捕获 error 退出。再修改一处正常前端源码，确认页面收到预期更新。

如果仍出现 file watcher error，继续处理它指向的文件；不要把这条日志当成已经全部修好。Linux 上若实际报的是 ENOSPC，还应按监听配额检查核对原因，错误事件被接住不会增加系统的监听额度。