VSCode打开Markdown文件卡死主因是插件深度递归解析标题结构且无节流，重点排查yzane.markdown-pdf、shd101wyy.markdown-preview-enhanced等高危插件，禁用其自动TOC更新、KaTeX/Mermaid渲染等配置可显著缓解。

VSCode 因插件导致卡死（尤其是打开 Markdown 文件后无响应、右键菜单空白、格式化卡住）时，问题大概率出在 markdown 相关扩展或其依赖的语言服务上，不是所有“Markdown 插件”都安全，有些会在解析大纲（TOC）、实时预览或渲染含大量标题的文档时直接拖垮主线程。

为什么 Markdown 文件一打开就卡？重点查这三类插件

不是文件大才卡，而是某些插件对 ## 标题、### 子标题 等结构做深度递归解析，且未设节流或超时。常见高危组合：

• yzane.markdown-pdf：生成 PDF 时同步调用 Chromium 渲染，若本地没装 Chrome 或版本不兼容，会卡在 spawn 阶段，且不报错
• shd101wyy.markdown-preview-enhanced：默认开启数学公式（KaTeX）+ Mermaid + PlantUML 实时渲染，任一依赖缺失（如 mermaid-cli 未安装）就阻塞整个预览线程
• bierner.markdown-checkbox 或 docsmsft.markdown-editing：监听 onDidChangeTextDocument 过于频繁，在编辑长文档时反复触发 TOC 重生成，CPU 持续 >90%

Developer: Show Running Extensions 看什么？

运行该命令后，别只看“已启用”，盯紧这两列：

• Activation Time (ms)：超过 800ms 的插件（如 shd101wyy.markdown-preview-enhanced 常达 2200ms）说明它在启动时就抢了主线程，哪怕你还没开任何 .md 文件
• Status：显示 Running 但 CPU 列持续跳动（尤其在滚动或输入标题时），基本可断定它正在后台暴力解析大纲

注意：Activated 状态不等于“干活了”，而 Running + 高 CPU 才是真正在啃资源。

知识产权官文PDF转markdown

Convert Chinese patent PDFs/DOCX/DOCs to structured Markdown. Supports patent publications (A/B/U) and office action documents (审查意见通知书/驳回决定/复审决定书/无效宣告请求审查决定书). Uses MinerU for high-quality OCR text extraction (falls back to Tesseract), Python scripts for

下载

禁用插件前先关掉这些配置项

很多卡顿不是插件本身烂，而是默认开启了“全量解析”。在设置里搜以下关键词并关闭：

• markdown.preview.doubleClickToSwitchToEditor → 设为 false（避免双击预览区触发重复渲染）
• markdown.extension.toc.autoUpdateOnSave → 设为 false（关掉保存即重刷 TOC，这是卡顿主因）
• markdown.extension.kaTex.enabled 和 markdown.extension.mermaid.enabled → 全部关掉，只在需要时手动启用
• files.associations 中检查是否误把 *.md 关联到了非标准语言模式（比如 markdown-md 或 mdx），应确保是 markdown

code --disable-extension 单点验证比二分更快

当你怀疑是某个 Markdown 插件，别跑 Developer: Start Extension Bisect——直接终端执行：

code --disable-extension shd101wyy.markdown-preview-enhanced

再打开同一份含 50+ 标题的 README.md。如果卡顿消失，立刻去插件页卸载它；如果还卡，换下一个高危 ID：

• yzane.markdown-pdf
• bierner.markdown-checkbox
• docsmsft.markdown-editing

真正麻烦的是那些不报错、不崩溃、只是让光标变慢半拍的插件——它们不会出现在 Extension Host 日志里，只能靠 --disable-extension + 实测对比来揪出。