ondidchangetextdocument监听编辑器内容任意变更而非文件保存，需用ondidsavetextdocument响应保存动作；监听前须校验uri.scheme==='file'；插件中不可直接使用chokidar，须通过子进程调用。
VSCode插件本身不提供“文件监听调试器”——你没法像断点调试普通函数那样，直接在 onDidChangeTextDocument 里设个断点就看到“谁改了哪行”。真要调试监听逻辑，得先分清监听的是什么事件、在哪注册、触发条件是否满足。
onDidChangeTextDocument 不等于“文件保存”
这是最常踩的坑：你在回调里加 console.log，结果一敲键盘就狂打日志，根本不是保存时才触发。
-
onDidChangeTextDocument监听的是编辑器内容任意变更，包括光标移动、输入、粘贴、撤销——每毫秒都可能触发多次 - 它不关心文件是否已写入磁盘，也不等
fs.writeFile完成 - 若想只响应保存动作，请换用
workspace.onDidSaveTextDocument - 监听前务必加守卫：
if (event.document.uri.scheme !== 'file') return，否则设置页、输出面板、REPL 等非文件文档也会进回调
文件系统级监听（如 chokidar）在插件里跑不起来
VSCode 插件运行在受限的 Extension Host 进程中，不能直接 require('chokidar') 或调用 fs.watch ——会报 Cannot find module 'chokidar' 或权限拒绝。
- chokidar 必须放在独立 Node.js 子进程里运行（比如通过
child_process.spawn调起一个node watch.js） - 插件主进程只能通过 IPC（如
vscode.window.createTerminal启动命令，或用vscode.env.openExternal打开本地服务）间接通信 - 别试图在
activate里awaitchokidar 初始化——activate必须同步返回，否则插件加载失败 - 真实项目中，更推荐把文件监听逻辑抽离为 CLI 工具（如
chokidar-cli），插件只负责启动/停止该进程并解析 stdout
调试监听逻辑必须绕过“自动重载”干扰
VSCode 插件开发时默认启用 Extension Development Host，每次改代码会自动重载整个插件进程。这会导致你刚设好的监听器被销毁，console.log 看不到连续输出。
- 临时禁用热重载：在 launch.json 的
configurations中添加"runtimeArgs": ["--disable-extensions"]，再手动 F5 启动目标插件实例 - 监听器注册后，务必将返回的
Disposable推入context.subscriptions，否则重载时旧监听不会被清理，新旧回调会叠加执行 - 验证监听是否生效，别只看控制台：在回调里加
vscode.window.showInformationMessage(`Changed: ${event.document.fileName}`)，弹窗比日志更可靠 - 如果监听的是工作区外路径（比如全局配置目录），需显式请求权限：
vscode.workspace.fs.stat(uri)前先vscode.workspace.fs.createFileSystemWatcher并捕获拒绝错误
真正难的不是写监听，而是判断该监听哪一层——编辑器事件？文件系统事件？还是用户保存行为？选错层级，调试就永远对不上号。
