VSCode插件无法监听重命名事件本身，只能通过拦截editor.action.rename命令或监听onDidChangeTextDocument并结合变更特征（如多处同名替换、防抖过滤）来响应其副作用。
重命名事件本身不可监听，只能响应其副作用
VSCode 的语言服务（如 TypeScript Server、Java Language Server）在执行重命名时，textDocument/rename 是一个 LSP 请求，由客户端（VSCode）发起、服务端（语言服务器）处理并返回 WorkspaceEdit。这个过程**没有公开的“重命名完成”事件供插件订阅**——插件无法直接监听“用户刚重命名了某个函数”这类语义事件。
真正可捕获的是重命名操作引发的底层文档变更：
-
workspace.onDidSaveTextDocument：适用于重命名后手动保存的场景，但无法区分是重命名改的还是用户自己编辑的 -
workspace.onDidChangeTextDocument：更灵敏，但每键入一个字符都触发，需结合内容差异分析判断是否为批量重命名所致 - 最可靠路径：监听
textDocument/didChange后，检查变更是否来自WorkspaceEdit应用（即是否含多处小范围替换、集中在同一符号名上），但这需自行实现 diff 逻辑，无现成 API
替代方案：拦截并增强重命名命令本身
虽然不能监听重命名“发生”，但可以劫持它“怎么发生”。VSCode 允许插件通过 commands.registerCommand 覆盖内置命令，前提是 ID 完全一致：
- 重命名命令 ID 是
editor.action.rename，不是rename或其他变体 - 在
activate中注册同名命令：vscode.commands.registerCommand('editor.action.rename', async () => { /* 自定义逻辑 */ }) - 必须在调用前先获取原命令引用：
const originalRename = vscode.commands.executeCommand.bind(vscode.commands, 'editor.action.rename')，否则会无限递归 - 可在调用
originalRename()前/后插入钩子，比如记录旧名、新名、影响文件数，或弹窗确认
注意：覆盖该命令会影响所有语言的重命名行为，若只针对某语言（如 TypeScript），需在钩子里判断 vscode.window.activeTextEditor?.document.languageId === 'typescript'。
监听重命名后的文件变更要防抖+过滤
若你目标是“重命名完成后自动做点事”（如刷新自定义大纲、更新外部索引），workspace.onDidChangeTextDocument 是最常用入口，但必须规避高频误触：
- 每次触发都应检查
event.contentChanges.length—— 真实重命名通常产生 3–20 个TextChange，而单字符编辑只有 1 个 - 提取所有变更中的文本片段，统计是否大量出现相同旧名 → 新名的替换模式（例如连续 5 处
fetchData→getData） - 用
setTimeout+clearTimeout实现 300ms 防抖，避免编辑中途多次触发 - 务必加守卫：
if (event.document.uri.scheme !== 'file') return，跳过设置页、输出面板等非文件文档
为什么不要依赖 onDidChangeTextEditorSelection 或其他编辑器事件
这些事件和重命名无因果关系：
-
onDidChangeTextEditorSelection只反映光标移动，用户按F2后还没输新名时就已触发，无法关联到最终结果 -
onDidChangeActiveTextEditor在切换标签页时触发，与重命名完全无关 - 试图从选区文本反推重命名意图（比如检测是否选中了标识符）极不可靠：用户可能只是在查文档、写注释，或重命名中途取消
- 语言服务器日志（如
TypeScript: Open TS Server Log）属调试通道，无稳定结构，不建议用于生产逻辑
重命名的语义闭环只存在于语言服务器内部；插件能抓到的，永远是它落地后的“涟漪”——文档内容变化。把精力放在识别这些涟漪的特征上，比等待一个不存在的“重命名完成事件”更务实。
