ctrl+k, ctrl+n 的 n 是语法作用域中 meta.* 前缀的嵌套次数，如 python 中 def 行属 meta.function.python（level 2），js 中 function 可能为 level 3；层级无效主因是作用域链断裂，如装饰器跨行、docstring 紧贴 def、缩进混用或插件冲突；修复需先确认语言识别正确、查 scope name、禁用冲突插件；fold_by_level 命令更可控，仅匹配指定 level 的 meta.function；gutter 折叠按钮不显示是因 "fold_buttons": true 未启用。
Ctrl+K, Ctrl+N 折叠层级到底怎么看数字？
这个 N 不是缩进空格数，也不是“函数嵌套几层”，而是当前语言语法定义中 meta.* 作用域的嵌套深度。比如 Python 文件里，import 和顶层赋值常在 source.python 直接子级（level 1），而 def 多落在 source.python meta.function.python（level 2）。JS 中 function 可能是 level 3，{ 块反而是 level 4。
验证方法：光标停在目标行（如 def foo():），按 Ctrl+Shift+P → 输入 Developer: Show Scope Name 回车，看状态栏输出：
- 若含
meta.function.python，说明它被识别为可折叠结构，且层级数字就是其meta.前缀出现次数 - 若只有
source.python，那Ctrl+K, Ctrl+2必然无效——不是快捷键错了，是语法没识别到
为什么 Ctrl+K, Ctrl+2 有时只折一半函数？
根本原因是作用域链断裂，常见于以下情况：
- 装饰器跨行写，比如
@cache单独一行、紧贴def上方且中间无空行 → 解析器把@当作独立 scope，跳过后续meta.function -
def行紧挨 docstring，如def f(): """doc"""; pass→ 某些语法包合并识别，折叠起点偏移 - Tab 和空格混用缩进 → 语法高亮器提前终止 scope 推导，
meta.block链断掉 - 安装了冲突插件（如旧版
Python Improved）覆盖原生语法包的 folding 规则
修复顺序：先确认右下角显示 Python（非 Plain Text），再查 show_scope_name 输出，最后禁用可疑插件。
fold_by_level 命令比快捷键更可控
Ctrl+K, Ctrl+N 是快捷键绑定，但底层调用的是 fold_by_level 命令。直接调用它更灵活，也更容易试错：
- 先确保一个
def行能被Ctrl+Shift+[正常折叠（否则fold_by_level也无效） -
Ctrl+Shift+P→ 输入fold_by_level→ 回车 → 依次输入2、3、1（Python 通常从 2 开始；JS/TS 常需 3） - 输错数字不会报错，只是静默失败，换下一个就行
- 该命令只匹配
meta.function+ 指定 level 的组合，if块即使同层也不会被误折
折叠按钮不显示？不是功能坏了，是设置关了
折叠成功但左侧 gutter 没三角图标，大概率是 UI 渲染开关被关了：
- 打开
Preferences → Settings - 确认有这两行（没有就手动加）：
"fold_buttons": true"fade_fold_buttons": false - 保存后重启 Sublime 或重载文件，图标立刻出现
注意：改这些设置只影响按钮显示，不影响折叠逻辑本身。真正决定“能不能折”的，永远是语法定义里的 fold: true 和作用域识别是否完整——这点最容易被忽略，也最难排查。
