VS Code的createFileSystemWatcher默认不递归监听子目录，需用/显式启用；需校验uri存在性、避免同步I/O、关闭冗余事件、多根工作区需遍历创建、禁用时必须dispose防止泄漏。
为什么 vscode.workspace.createFileSystemWatcher 监控不到子目录新增文件
默认情况下，createFileSystemWatcher 的 glob 模式不递归匹配嵌套路径。比如传入 'src/*.ts'，只会监听 src/ 下一级的 .ts 文件，src/utils/helper.ts 这类路径完全不会触发事件。
实操建议：
- 用双星号
**显式启用递归：改用'src/**/*.ts'或更宽泛的'**/*.ts' - 避免过度宽泛——
'**'会监听整个工作区，可能引发性能抖动或权限拒绝（尤其含node_modules） - 若需排除特定目录，用
vscode.RelativePattern构造带exclude的 pattern，比字符串 glob 更可控
监听事件触发但 uri.fsPath 报错“Cannot read property 'fsPath' of undefined”
这是典型异步竞态：onDidCreate 回调中直接访问 uri.fsPath，但某些场景（如快速重命名+保存）下，VS Code 可能传入 undefined 或空对象。
实操建议：
- 始终做存在性校验：
if (uri && uri.fsPath) { ... } - 不要依赖
uri.fsPath做同步文件操作（如fs.readFileSync），因为文件可能尚未落盘；改用workspace.fs.readFile(uri)（返回 Promise，自带时序保障） - 对
onDidChange事件，注意它只表示“文件被修改”，不代表内容已写入磁盘——可加setTimeout(..., 50)做轻量防抖，或监听onDidSaveTextDocument更稳妥
插件启用后 CPU 占用飙升，FileSystemWatcher 是罪魁祸首吗
是的，高频变更路径（如构建输出目录 dist/、日志文件、热重载临时文件）会持续触发事件，每个回调若含同步 I/O 或复杂解析，极易拖垮主进程。
实操建议：
- 用
ignoreCreateEvents/ignoreChangeEvents/ignoreDeleteEvents参数关闭不需要的事件类型 - 在
onDidCreate中快速过滤非目标文件：if (!uri.fsPath.endsWith('.json')) return;，越早 return 越省资源 - 避免在监听回调里启动子进程（如
execSync）、读大文件或调用未缓存的网络请求 - 开发阶段用
console.time('watch')+console.timeEnd('watch')定位耗时环节
如何让监控在多根工作区（Multi-root Workspace）下正常工作
vscode.workspace.createFileSystemWatcher 默认只作用于第一个工作区文件夹，其余根目录完全不监听。
实操建议：
- 遍历
vscode.workspace.workspaceFolders，为每个文件夹单独创建 watcher - 注意：每个 watcher 需独立注册事件回调，不能复用同一函数引用后反复赋值——否则只有最后一个生效
- 若需统一处理逻辑，把核心逻辑抽成纯函数，再在各 watcher 回调中调用，例如：
onDidCreate: uri => handleFileEvent(uri) - 当用户增删工作区根目录时，记得手动 dispose 旧 watcher 并创建新 watcher（监听
workspace.onDidChangeWorkspaceFolders）
dispose()，会导致事件监听器泄漏，下次启用时叠加注册，触发次数翻倍。务必在 deactivate 钩子中清理所有 watcher 实例。 
