Ctrl+F9排序异常因sort_lines仅比较每行首非空白字符ASCII值：未选中时排全文件，部分选中则静默失败，跨行选中不含换行符则忽略末行，全空行排最前，Banana因B(66)小于a故在apple前。
Ctrl+F9 为什么排得不对？先看选区和首字符
Sublime 的 sort_lines 命令不看整行语义，只取每行第一个非空白字符（跳过开头所有空格、制表符）的 ASCII 值比较。这意味着：
- 没做任何选择就按
Ctrl+F9→ 它会重排整个文件，不是“没反应”，是误操作 - 用鼠标框选中间几个字母（比如只选中 “cat” 而非整行）→ 命令静默失败，状态栏不显示
lines - 跨行选择但末尾没包含最后一行的换行符 → 那一行被完全忽略
- 行首全是空格 → 拿后面第一个可见字符比；全空白行 → 排最前
-
Banana一定在apple前面，因为B（66）a（97）
验证是否选对：右下角状态栏必须显示类似 5 lines，而不是 5 characters 或没提示。
降序怎么搞？别找菜单，用两步法
2026 年主流版本已移除 Edit → Sort Lines → Sort Lines (Z-A) 菜单项。依赖菜单会卡住，正确路径只有：
- 先
Ctrl+F9（Win/Linux）或Cmd+F9（macOS）升序排好 - 全选已排序区域（确保含换行符），再按
Ctrl+Alt+R（Win/Linux）或Cmd+Option+R（macOS）执行reverse
reverse 不是重新排序，只是翻转当前顺序——如果原始是乱序，先 reverse 再 sort，结果还是乱的。顺序不能颠倒。
数字排序总出错？补零 or 插件
sort_lines 把 10.txt 和 2.txt 当字符串比：'1'（49）'2'（50），所以 10.txt 排前面。这不是 bug，是设计如此。
- 临时解法：手动补零，如
01.txt、02.txt、10.txt - 长期解法：装插件
Sort Numbers，命令面板输Sort Numbers: Sort Ascending - 想自然排序（忽略大小写 + 数值优先）：装
Natural Sort，调用Natural Sort: Sort Ascending
原生 sort_lines 不支持数值解析，硬靠它排日志编号、版本号、IP 地址，必翻车。
去重为什么没删干净？排序是前置条件
Remove Duplicate Lines（快捷键 Ctrl+Shift+U）等价于 Unix 的 uniq：只删**连续重复行**。
- 原始是
apple、banana、apple、cherry→ 直接去重，四行全留 - 正确流程：先
Ctrl+F9升序 →apple、apple、banana、cherry→ 再Ctrl+Shift+U - 若含
Apple和apple，需先统一大小写：Ctrl+K、Ctrl+L全转小写，再排序去重
边界必须自己划清楚：哪些行属于同一逻辑块、是否保留空行、是否要预处理格式——Sublime 不猜意图，只执行命令。
