高频事件调试须用日志断点替代普通断点，配合条件过滤（如languageid或fspath）和计数器区分触发；deactivate需手动重载窗口验证，返回promise并加日志确认执行。
高频事件断点会卡死，必须用日志断点代替
直接在 onDidChangeTextDocument 或 onDidChangeSelection 这类每秒触发数十次的回调里打普通断点，调试器会瞬间卡住甚至崩溃。VSCode 的日志断点（Logpoint）才是正确选择——它不暂停执行，只输出表达式结果。
右键断点 → 选择 “Edit Breakpoint” → 输入类似 console.log('selection changed:', e.selections.length) 的语句，结尾加 || true 确保条件恒真。注意：不要写 debugger，也不要调用可能阻塞的函数（如 vscode.window.showInformationMessage）。
- 日志断点输出默认出现在调试控制台（Debug Console），不是终端（Terminal）
- 若需区分多次触发，可在表达式中拼入计数器，例如
counter++ + ': ' + JSON.stringify(e.selections) - 避免在日志断点中访问深层嵌套对象（如
e.document.getText().length），可能拖慢响应
如何过滤掉无关触发，只看目标文档或语言
高频事件常被所有打开的编辑器触发，但你通常只关心某类文件（比如 .ts）或某个特定文档。这时必须用条件断点，而不是靠肉眼筛选日志。
编辑断点条件时，写完整判断逻辑，例如：
e.document.languageId === 'typescript' && e.document.fileName.includes('src/')
或者更精确地锁定单个文件：
e.document.uri.fsPath === vscode.Uri.file('/path/to/your/file.ts').fsPath
- 用
===而不是==，避免类型隐式转换导致误判 -
e.document.uri.fsPath比e.document.fileName更可靠，后者不含路径，多窗口同名文件会冲突 - 条件表达式里不能用
await，也不支持异步函数；如需异步逻辑，请移至命令或独立 handler 中处理
为什么 deactivate 不会被自动调用，以及怎么验证卸载逻辑
deactivate 函数不会在插件调试期间自动执行——VSCode 默认保持插件激活状态直到你手动关闭 Extension Development Host 窗口。所以你在 deactivate 里写的清理代码（如取消定时器、释放事件监听器）根本不会运行，也就没法验证是否真的生效。
要测试 deactivate，必须主动触发插件卸载：
- 在 Extension Development Host 窗口中按
Ctrl+Shift+P，输入并执行Developer: Reload Window—— 这会强制卸载再重载插件，触发deactivate - 确保
deactivate返回一个Promise（如果内部有异步清理），否则 VSCode 可能未等完成就结束进程 - 在
deactivate开头加一条console.log('deactivating...')并配合日志断点，比设普通断点更易确认是否走到了这一步
测试真实高频场景，别只靠手动模拟
手动敲字、点鼠标产生的事件频率远低于真实用户（比如快速滚动、批量粘贴、格式化工具触发）。想压测你的事件逻辑，得用自动化方式生成真实负载。
在测试代码中，用 vscode.workspace.textDocuments 找到目标文档，然后调用 vscode.window.activeTextEditor?.edit() 批量插入内容：
await editor.edit(builder => {
for (let i = 0; i
- 这种批量编辑会合并为一次
onDidChangeTextDocument事件，不代表高频；如需逐行触发，需拆成多个edit()调用（但注意节流限制） - 真实高频事件还来自其他插件（如 Prettier、ESLint），所以务必在干净的 Extension Development Host 环境中测试，禁用无关插件
- 性能敏感逻辑（如语法高亮计算）建议抽离到 Web Worker 或用
setTimeout(..., 0)延迟执行，避免阻塞主线程
高频事件调试最易忽略的是节流与防抖的实际生效位置——它不在你注册监听的地方，而在 VSCode 底层事件分发机制里。你看到的“每秒 20 次”可能是被合并后的结果，别假设每次编辑都对应一次回调。
