fold_by_level按语法作用域层级折叠而非缩进，失效主因是光标未置函数/类起始行、装饰器或docstring导致作用域断裂、输错数字、语言误设；fold_selection需先选区再快捷键，仅会话有效；原生不支持HTML风格标记；fold_all暴力折叠所有结构，fold_by_level精准控制指定层级。
为什么 fold_by_level 总是没反应
因为 fold_by_level 不是“按缩进空格数”折，而是按语法作用域嵌套深度（scope level）匹配。它只对当前语法定义中明确标记了嵌套层级的结构生效——比如 Python 的 meta.function.python 被定义在 level 2，JS 的 meta.function.js 可能在 level 3，但这些值由语法包硬编码，不统一。
常见失效原因：
- 光标没停在能被识别为函数/类起始行的位置（如
def行未显示meta.function.python，用Ctrl+Shift+P → Developer: Show Scope Name验证） - 装饰器跨行（
@decorator单独一行紧贴def）或 docstring 紧挨着def行，导致作用域链断裂 - 输错数字：输入
fold_by_level后回车，再键入数字（如2），不是快捷键组合；输错无提示，静默失败 - 文件语言被误设为
Plain Text或非标准语法（如Python Improved未定义折叠规则）
手动选区折叠（fold_selection）怎么用才稳
fold_selection 是唯一不依赖语法、缩进或作用域识别的折叠方式，适合 JSON 配置块、日志段、base64 字符串、临时注释等场景。
操作要点：
- 必须先选中连续多行（鼠标拖选，或多次按
Ctrl+L选中多行） - Windows/Linux：按
Ctrl+Shift+Alt+[；macOS：按Cmd+Ctrl+Option+[ - 折叠后 gutter 出现独立 ▶ 图标，点击即可展开/收起，不影响其他自动折叠块
- 该折叠仅存在于当前会话：关闭文件即丢失，不写入磁盘，
Ctrl+K, Ctrl+J（unfold_all）也不会还原它
想用
Sublime 原生不支持 / 这类 HTML 风格的折叠标记。这类功能需要插件（如 CodeFold 或自定义 .sublime-syntax 文件）才能启用，但存在明显风险：
- 官方语法引擎不解析这些注释，强行添加会导致高亮错乱或崩溃
- 第三方插件可能与 BracketHighlighter、Anaconda 等常用插件冲突
- 更新 Sublime 后，插件常因 API 变更失效，维护成本高
- 同一份代码在不同机器上表现不一致（插件未安装就完全不可用）
真要逻辑分段折叠，优先用 fold_selection，或者把配置抽成独立文件（如 config.json），用对应语法包启用原生折叠。
fold_all 和 fold_by_level 的关键区别在哪
fold_all（Ctrl+K, Ctrl+0）是暴力遍历：无视层级，把所有已识别的可折叠结构（import、def、class、if、顶层注释块、JSON 根对象）全收掉；而 fold_by_level 是精准控制：只折指定 scope level 的结构，但前提是该 level 在当前语法中确实有定义且被识别。
典型差异：
-
Ctrl+K, Ctrl+1不等于“只折函数”，它折的是 scope level = 1 的所有结构——Python 中可能是if __name__ == "__main__":和模块级变量，而非def -
fold_by_level 2在标准 Python 语法中大概率折函数，但在某些自定义语法中可能对应 class 内部的 for 块 -
fold_all对大文件（>10MB）响应慢甚至卡住，fold_by_level则基本不受文件大小影响 -
fold_all会受缩进一致性干扰（Tab+Space 混用导致作用域识别失败），fold_by_level同样依赖底层识别，所以两者都逃不开语法前提
最易被忽略的一点：所有折叠命令都要求右下角状态栏显示真实语言名（如 Python），而不是 Plain Text —— 这个条件不满足，其余全是空谈。
