根本解法是插入TOC时显式设置max_level为3或4，或在用户配置中添加{"max_level": 3}；已有TOC需手动删除后重新插入才能生效，且须确保插件版本≥v3.6、语法模式为Markdown。

MarkdownTOC 生成的目录太深，导致渲染卡顿怎么办？

不是目录本身卡，而是 Sublime 在解析和高亮超长 TOC（比如 20+ 级嵌套）时，语法分析器会反复回溯匹配，拖慢整个文件响应。尤其当文档含大量 ### ~ ###### 标题且未限制层级时，MarkdownTOC 默认生成全深度目录，触发 Sublime 的语法高亮引擎过载。

• 临时缓解：右下角切换为 Plain text，关闭语法高亮，滚动/编辑立刻变快
• 根本解法：在 TOC 插入命令中显式指定最大深度，避免生成冗余层级
• 操作路径：Ctrl+Shift+P → 输入 MarkdownTOC: Insert Table of Contents → 弹出配置面板后，把 max_level 改为 3 或 4（多数技术文档用不到 5 级以上）
• 若常用固定深度，可写进用户配置：Preferences → Package Settings → MarkdownTOC → Settings，添加：

  {"max_level": 3}

为什么改了 max_level 还是卡？检查这些地方

常见错因不是配置没写，而是插件没读到——MarkdownTOC 只在「插入新 TOC」时读取设置，已存在的 TOC 不会自动重生成或收缩层级。

Xlsx To Markdown

文档转 Markdown 转换器 - 将 DOCX、PPTX、Excel 文件转换为 Markdown。用于从 Word 文档、PowerPoint 演示文稿或 E... 提取内容。

下载

• 已有 TOC 不会随配置变更自动更新，必须手动删掉旧 TOC，再执行一次 MarkdownTOC: Insert Table of Contents
• 确认当前文件语法是 Markdown（右下角状态栏显示），不是 Markdown GFM 或 Plain text，否则插件命令可能灰掉或不生效
• 某些老版本 MarkdownTOC（如 v1.x）不支持 max_level 配置项，升级到 v3.6+ 才可靠 —— 在 Package Control → Upgrade Package 里搜 MarkdownTOC 确认版本
• 如果用了 MarkdownEditing 插件，它的语法高亮规则可能覆盖 TOC 的样式解析，导致渲染异常；可临时禁用它测试是否改善

大型文档里 TOC 占用太多内存？试试只渲染锚点不渲染结构

真正吃内存的是 TOC 的 HTML 渲染层（尤其是配合 MarkdownPreview 时），而非纯文本 TOC 行本身。如果你只是需要跳转功能，不需要实时预览 TOC 样式，可以绕过渲染瓶颈。

• 关闭 MarkdownPreview 的自动刷新，改为手动预览：Ctrl+Shift+P → Markdown Preview: Preview in Browser，之后保存不再触发刷新
• 在 MarkdownPreview 设置里关掉 github_mode 和 enable_math，这两项会额外加载 JS 解析器，对纯 TOC 文档毫无必要
• 用 Ctrl+R（Goto Symbol）代替 TOC 导航：Sublime 原生符号索引比插件生成的 TOC 更轻量，且不依赖语法高亮深度
• 如果文档确实超过 10MB，直接放弃 TOC 实时渲染，用外部工具（如 mdtoc CLI）生成静态 HTML 目录页单独打开

别让 TOC 成为性能单点故障

TOC 卡顿往往只是表象，背后常连着更底层的问题：比如 index_files 开着扫整个项目、缓存目录堆积、或 MarkdownEditing 的高亮规则过于复杂。单独调 max_level 能压一部分压力，但若文件一打开就卡，优先去清 Index 目录、关 index_files、切回 Plain text 模式验证基线性能。TOC 是锦上添花的功能，不是编辑器运转的前提。