同时启用auto rename tag和auto close tag会导致卡顿，因二者均监听ondidchangetextdocument事件并重复解析dom，引发cpu占用翻倍、响应延迟等问题。
Auto Rename Tag 和 Auto Close Tag 同时启用会卡顿
这两个插件都监听 onDidChangeTextDocument 事件，对 HTML/XML 标签做实时 DOM 结构分析。一旦同时启用，它们会在每次输入、删除、粘贴时各自触发一次完整解析，CPU 占用翻倍，光标移动和回车响应明显延迟。
常见现象包括：敲 <div> 后不自动补全闭合标签、重命名开始卡顿半秒、保存时编辑器短暂无响应、<code>Developer: Show Running Extensions 中二者 CPU 列持续高于 150MB。
- 禁用
Auto Close Tag，保留 VS Code 内置的editor.autoClosingTags（默认开启）即可满足基础闭合需求 - 若必须用
Auto Rename Tag，请确认它没和Bracket Pair Colorizer 2或Highlight Matching Tag同时激活——三者叠加会进一步加重 DOM 遍历负担 - 检查
settings.json是否有重复配置："auto-close-tag.enableAutoCloseTag"和"auto-rename-tag.enableRenameTag"不应同时设为true
如何验证是这两个插件在抢资源
不用重启多次，用命令行快速隔离：
- 终端执行
code --disable-extension formulahendry.auto-close-tag --disable-extension formulahendry.auto-rename-tag，启动后测试输入/重命名是否流畅 - 如果恢复，再单独启用其中一个：
code --disable-extension formulahendry.auto-close-tag，观察是否卡顿再现 - 若只启
auto-rename-tag就卡，说明它当前版本（如 v0.1.10）与 VS Code 1.118 的新 DOM API 兼容性有问题，需降级到 v0.1.8 或换用renovate.vscode-renamer
注意：Developer: Open Extension Host Log 里可能看不到明显报错，因为冲突发生在高频事件处理阶段，日志只记录崩溃，不记录“慢”。
VS Code 1.118 下更隐蔽的冲突点
新版对标签匹配逻辑做了底层优化，但部分插件仍沿用旧的 vscode.workspace.onDidChangeTextDocument 监听方式，导致事件回调排队阻塞主线程。
- 打开
Developer: Toggle Developer Tools→ Console，搜索rename或close，看是否有Range is out of bounds类警告——这是插件用过期TextDocument对象读取内容的典型表现 - 运行
Developer: Show Running Extensions，重点关注Status列：若显示Activated但Startup Time> 800ms，说明它在初始化时就加载了冗余语法树解析器 - 检查
files.watcherExclude是否漏配"**/node_modules/**"：未排除会导致插件反复扫描node_modules里的模板文件，加剧卡顿
真正麻烦的是“没报错却一直卡”
这类问题不会触发 Extension host terminated unexpectedly，也不会出现在控制台红字里。它只是让每个按键事件多等 120–300ms 才响应——足够让人觉得“编辑器变迟钝”，但又找不到明确错误源。
这时候必须靠 Developer: Open Process Explorer 看 RSS 内存占用：如果 formulahendry.auto-rename-tag 进程在空闲状态下 RSS 仍稳定在 200MB+，基本可以判定它内部缓存了整个项目 HTML 结构树且没释放。删掉 ~/.vscode/extensions/formulahendry.auto-rename-tag-* 目录比禁用更彻底。
