Ctrl+H无响应大概率是扩展在activate()或事件监听中触发同步阻塞，导致主线程挂起；应先用code --disable-extensions验证，再通过Developer: Start Extension Bisect二分定位，结合Extension Host日志中Activating extension及ERR!报错精准识别问题插件。
Ctrl+H 按下后编辑器无响应，不是卡在 UI，是扩展宿主被阻塞
插件更新后 Ctrl+H 卡死，大概率不是界面渲染问题，而是某个扩展在 activate() 或监听 onDidChangeTextEditorSelection 时触发了同步阻塞逻辑（比如递归遍历大目录、未加 timeout 的 fs.readFileSync），直接拖垮主线程。此时你点不动替换框、光标不闪烁、甚至无法切换标签页——这不是“慢”，是线程挂起。
验证方式极简：code --disable-extensions 启动，再按 Ctrl+H。若立刻弹出且可操作，100% 是扩展导致；若仍卡，才需查文件编码、只读状态或系统级输入法劫持。
- 别信“刚更新的插件肯定没问题”——很多插件更新后会默认开启新功能（如 GitLens 的
gitlens.advanced.caching.enabled） - 禁用插件后必须执行
Developer: Restart Extension Host，否则旧进程残留，内存和监听器照常运行 - 某些插件（如
ms-python.python）即使被禁用，也会在启动时尝试初始化 Python 环境，得删掉~/.vscode/extensions/ms-python.python-*彻底隔离
Replace in Files 执行一半卡住，看 Extension Host 日志里最后一行
全局替换中途冻结、进度条停住、Git 状态没变化，说明替换逻辑被某个插件中断。VSCode 的 Replace in Files 是异步批量写入，但若某插件注册了 workspace.onWillSaveTextDocument 并在回调里做了耗时同步操作（比如调用外部 CLI 且未设超时），整个流程就会卡死。
打开 Developer: Toggle Developer Tools → Console 标签页，搜索 ERR! 或 Extension host terminated unexpectedly；更关键的是切到 Output 面板 → 选 Extension Host，往上翻找崩溃前最后一句：
- 若看到
Activating extension 'esbenp.prettier-vscode'后紧接RangeError: Maximum call stack size exceeded，说明它在格式化前试图解析 AST 时无限递归 - 若日志末尾是
ERR! spawn ENOENT: python3，代表某个插件（如 linter）硬依赖本地命令但路径未配置，又没 fallback，就一直等 - macOS 用户额外检查系统快捷键：
Cmd+Alt+F被系统“聚焦窗口”功能占用，会导致搜索面板无法接收输入
正则替换后内容错乱，其实是插件劫持了 document change 事件
你填了 class="([^"]+)" → class="$1 is-primary"，点击 Replace All，结果部分 class 值变成 class="undefined is-primary" 或直接消失——这通常不是正则写错了，而是某个插件（尤其是代码补全类、AI 辅助类）监听了 onDidChangeTextDocument，并在 VSCode 写入前/后强行修改了变更对象（TextDocumentContentChangeEvent），把捕获组覆盖成了空值。
这类问题在插件更新后高频出现，因为新版 SDK 对事件参数校验更严，而旧插件代码仍按老方式访问 event.contentChanges[0].text，忽略多变更场景。
- 临时绕过：执行
Developer: Start Extension Bisect，3 轮内能锁定（常见嫌疑：github.copilot、tabnine.vscode-tabnine、mutantdino.resourcemonitor） - 不要依赖
extensions.disabledExtensions配置禁用——它只阻止激活，不卸载已注册的事件监听器 - 真实生效的禁用动作只有两个：
code --disable-extension xxx启动，或删扩展目录后重启
禁用高危插件后仍卡，检查 files.watcherExclude 和语言模式
即使清空所有插件，Ctrl+H 还是卡，问题可能藏在 VSCode 自身的文件监视机制里。插件更新常触发 files.watcherExclude 规则重载，若配置了模糊路径（如 "**/node_modules/**"）或正则语法错误，FSWatcher 会陷入无限扫描循环，连带拖慢所有文本操作。
另一个隐蔽原因：当前文件被识别为错误语言模式（比如 .js 文件右下角显示 Plain Text），某些插件（如 dbaeumer.vscode-eslint）会在非 JS 模式下跳过校验，但其底层语言服务仍在后台加载，占用大量内存和 CPU。
- 运行
code --status，重点看Files区域是否显示watcher: ready；若卡在initializing，立刻检查files.watcherExclude是否含非法 glob - 右键编辑器空白处 →
Reopen Editor With Language→ 选正确语言（如JavaScript），再试 Ctrl+H - 大项目务必配
"files.watcherExclude": {"**/dist/**": true, "**/build/**": true}，避免 watcher 误扫输出目录
code --disable-extensions 和 Developer: Open Process Explorer 双验证，单看控制台日志容易漏掉静默阻塞。 
