Ctrl+F9或Cmd+F9无反应或排错行，90%因选区错误：必须选中含换行符的完整多行，状态栏显示“x lines”才生效；Banana排在apple前是因默认按首非空白字符ASCII值排序（B=66<a=97）。
Ctrl+F9（Windows/Linux）或 Cmd+F9（macOS）就是排序快捷键，但按下去没反应、排错行、结果不像预期——90% 是选区没选对，不是快捷键失效。
为什么 Ctrl+F9 没反应或只排了一行？
sort_lines 命令根本不响应“部分选择”或“光标悬停”，它只认一种输入：含换行符的完整行块。常见失败场景：
- 只点了一下光标（没拖选）→ 它对整个文件排序，大配置文件可能卡顿或误改
- 用鼠标框选中间几个字符（比如只选中
log）→ 不被识别为多行，命令静默失败 - 选区末尾没包含最后一行的换行符（光标停在行末但没向下拉）→ 该行被完全跳过
- 右下角状态栏显示
5 selections或只有坐标 → 实际未满足“多行”条件；必须看到5 lines
排序结果为什么 Banana 在 apple 前面？
这不是 bug，是 sort_lines 的确定性行为：它只取每行第一个非空白字符（B 和 a），按 ASCII 值比较。B=66，a=97，所以 Banana 必然靠前。其他典型表现：
- 数字行如
10.txt、2.txt排序后是10.txt→2.txt（因为首字符12） - 空行或全空格行没有“第一个非空白字符”，被视为最小值，永远排最前
- 行首有缩进（空格或
\t）→ 它跳过空白后取第一个可见字符；但若整行只有空格，则该行排最前
如何真正可靠地升序一次？
别依赖菜单路径，用预检+快捷键组合更稳：
- 先用
Ctrl+L（Win/Linux）或Cmd+L（macOS）逐行选中第一行 - 再按住
Shift+↓向下扩展，直到最后一行末尾（确保光标落在换行符之后） - 看右下角状态栏是否显示类似
7 lines；如果不是，重选 - 确认语法模式是
Plain Text（避免 Markdown/JSON 等结构干扰选区） - 按
Ctrl+F9（Win/Linux）或Cmd+F9（macOS）
降序、忽略大小写、去重这些怎么连用？
它们不是独立开关，而是有严格执行顺序的链式操作：
- 降序不能跳步：
Ctrl+F9升序 → 全选结果 →Ctrl+Alt+R（Win/Linux）或Cmd+Option+R（macOS）反转 - 忽略大小写无一键菜单：先
Ctrl+K, Ctrl+L全转小写 → 再Ctrl+F9；或命令面板输sort_lines_case_insensitive - 去重必须先排序：
Ctrl+F9→ 全选 →Ctrl+Shift+U；否则Ctrl+Shift+U只删连续重复行（等价 Unixuniq） - 高频降序建议自定义键位：在
Preferences → Key Bindings用户配置中加[{"keys": ["ctrl+shift+f9"], "command": "sort_lines", "args": {"reverse": true}}]
真正决定排序成败的，从来不是按哪个键，而是你是否提前判断清楚：哪些行属于同一逻辑块、哪些空格该忽略、大小写要不要统一、重复项是否混用格式——这些边界不手动控好，Ctrl+F9 就只是个触发器，不是解药。
