vscode.workspace.createfilesystemwatcher监听不到文件修改的根本原因是路径错误或被排除规则过滤，需用绝对路径、检查exclude设置、注册事件回调并保留watcher实例。
vscode.workspace.createFileSystemWatcher 为什么监听不到文件修改？
常见现象是调用 createFileSystemWatcher 后，改完保存文件，回调函数完全不触发。根本原因通常是监听路径没写对，或被 files.exclude / search.exclude 隐式过滤掉了。
必须用绝对路径（推荐 vscode.workspace.rootPath 或 vscode.workspace.workspaceFolders?.[0].uri.fsPath），不能用相对路径或 glob 模糊匹配（如 "**/*.js" 在某些系统上不可靠）；
检查用户设置里是否启用了排除规则，比如 "**/node_modules/**" 会直接屏蔽整个目录，watcher 无法穿透；
监听器创建后需显式注册事件回调：watcher.onDidChange 和 watcher.onDidCreate 是独立监听器，漏掉任一就收不到对应事件；
watcher 实例必须被保留在 extension context 中（例如 context.subscriptions.push(watcher)），否则会被 GC 回收，监听自动失效。
状态栏通知该用 statusBarItem 还是 showInformationMessage？
二者定位完全不同：showInformationMessage 是模态弹窗，打断用户操作，适合一次性关键提醒（如“配置已保存”）；createStatusBarItem 是常驻底部的轻量指示器，适合持续状态反馈（如“文件已锁定”“正在监听…”）。
如果想让用户一眼看到当前监听状态，优先用 statusBarItem：支持图标（$(file-symlink)）、颜色（item.color = new vscode.ThemeColor('statusBarItem.warningForeground')）、tooltip 和点击 command；
不要在 onDidChange 回调里频繁调用 showInformationMessage —— 多次触发会导致弹窗堆叠、焦点混乱，用户无法关闭；
真正需要“通知”时，可组合使用：状态栏显示简略状态（item.text = "$(sync~spin) Watching..."），点击后才用 showInformationMessage 展开详情。
如何避免文件变更通知抖动或卡顿？
chokidar 或 VS Code 原生 watcher 在保存瞬间可能触发多次事件（尤其 IDE 自动格式化 + 保存 + lint 多步写入），直接响应会导致状态栏闪烁、CPU 升高。
- 做简单节流：用
setTimeout缓存最后一次变更，延迟 150ms 后统一处理； - 比对变更内容：只在
event.uri.fsPath真正属于你关心的文件类型（如.ts、.json）时才更新； - 避免重计算：把文件读取、解析逻辑抽到异步任务里，状态栏只负责展示结果；
- 监听
onDidSaveTextDocument替代底层 watcher —— 更精准、更轻量，适用于大多数“保存即通知”场景。
监听 Git 状态变化要不要自己实现？
不需要。VS Code 已内置 Git 扩展的状态广播机制，直接监听 vscode.extensions.getExtension('vscode.git')?.exports?.onDidChangeRepository（需先激活 Git 扩展）更稳定，且能拿到结构化状态（branch、HEAD、staged/unstaged 文件数）。
自己调 git status --porcelain 不仅慢，还容易因权限、子模块、符号链接等问题失败；
Git 扩展的事件不是实时的——它依赖 debounced 文件系统扫描，默认延迟约 300ms，所以你的通知也应接受这个节奏，别强行“毫秒级同步”；
注意：该事件只在 Git 仓库根目录下有效，若工作区含多个 repo，需遍历 vscode.workspace.workspaceFolders 分别监听。
真正的难点不在监听本身，而在判断“什么变更值得通知”——比如一次保存同时触发 lint、format、git index 更新，你得决定哪个信号优先、是否合并展示、旧通知要不要自动清除。这些逻辑没法靠 API 自动完成，必须手动设计状态机。
