发布于2026-07-08 阅读(0)
扫一扫,手机访问
之前有不少朋友留言问sort-lines这个插件的用法,今天统一回复一下。
它的核心逻辑其实非常简单:只对选中的文本行做字典序排序,不解析语法、不理解变量作用域、也完全不处理嵌套结构。比如你选中一段 JSON 数组的 value 块,它会直接把 {"name": "zhang"} 排在 {"name": "li"} 前面——仅仅是因为 z 在字典序里比 l 大,而不是按 name 字段值排序。这一点特别容易踩坑。
有没有遇到过这样的情况:想让数字 10、2、100 按大小排,结果出来却是 10、100、2?没错,这就是字符串排序的典型表现。更常见的误用场景还包括:
Ctrl+A 全选归根结底,它就是个纯粹的文本行排序工具,不是代码分析器。
默认排序区分大小写,A 会排在 z 前面。如果你希望 apple 和 Zebra 按字母顺序自然排列,这里有个小机关:
Ctrl+Shift+P → 输入 Sort Lines: Sort Lines (Case Insensitive) → 回车Cmd+Shift+Psort-lines 是否为 enabled 状态哥们儿,这两个功能不走菜单入口,得靠命令面板精确调用:
Sort Lines: Reverse Lines(注意别和 Sort… reverse 搞混,那是另一回事)Sort Lines: Unique Lines——它不会自动先排序,要“去重并排序”,得先跑一次 Sort Lines: Sort Lines,再跑 Unique Linessort -u 或者写个小脚本会更省事排完序,代码错位了?别慌。sort-lines 只按行内容排序,完全不理会缩进的空格或 Tab。如果某几行前面有不等量空格,视觉错位几乎是必然的。
几个安全做法:
Ctrl+Shift+I(macOS 是 Cmd+Shift+I)自动对齐Editor: Convert Tabs to Spaces 统一格式Editor: Format),否则括号错位、冒号悬空这些问题会立刻冒出来还有个容易忽略的点:排序本身不改行尾换行符类型(CRLF vs LF)。但如果你在跨平台协作中频繁排序又提交,Git 可能会因为行尾差异产生一堆无意义的 diff。建议在项目级配置 .editorconfig,把 end_of_line = lf 锁死,一劳永逸。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8