sublime text 的 sort lines 插件可对格式规整的单行 css 声明做纯文本字母序排序，但不识别语法结构；csscomb 插件支持语义化分组排序，需配置 .csscomb.json，且不处理嵌套和 at-rule 内部声明。
用 Sort Lines 插件直接排序 CSS 声明块
sublime text 本身不识别 CSS 语法结构，所以不能“智能按属性名排序”，但可以安全地对选中的多行声明做纯文本字母序排列——前提是每行只写一个属性，且格式规整（Property: value; 开头，无缩进或注释混在行内）。
操作路径：选中要排序的声明块 → 右键 → Sort Lines（或快捷键 Ctrl+Shift+P 输入 Sort Lines 回车）。
- 必须确保每行以属性名开头，比如
color: #000;可以，margin: 0;（带空格）或/* comment */ padding: 0;会排错位置 - 如果用了 CSS 预处理器语法（如
@apply、&嵌套、变量$color），Sort Lines 会把它们当普通字符串排，结果不可控 - 排序是 ASCII 码序，
z-index会排在width后面（因为z>w），不是语义分组
安装和配置 CSSComb 插件实现语义化排序
真正按 CSS 属性逻辑分组（如 display 相关、box-model、typography）并排序，得靠 CSSComb。它读取项目根目录下的 .csscomb.json 配置，支持自定义顺序、缩进、分号策略。
安装后，在 CSS 文件里右键选择 CSSComb: Sort 即可生效。默认配置已覆盖主流规范（如 stylelint 的推荐顺序），但要注意：
立即学习“前端免费学习笔记（深入）”；
- 必须在项目根目录放
.csscomb.json，否则插件可能回退到默认规则，导致flex相关属性被拆散 - Sublime 的
CSSComb插件不支持嵌套 CSS（如 scss 的&:hover块内属性），只处理标准 CSS 块内的声明 - 如果文件里有
@keyframes或@media块，CSSComb 默认跳过它们内部的声明——这不是 bug，是设计如此
为什么不能用正则替换 + Sort Lines 搞定所有情况？
有人试过先用正则把 property: value; 提出来再排序，比如搜索 ^[s]*([a-z-]+):s*(.+?);$。这看似聪明，实际容易翻车：
- 匹配会漏掉带浏览器前缀的属性（如
-webkit-transform），因为正则没覆盖-开头 - 如果某行有多个声明（
margin: 0; padding: 0;），正则只捕获第一个，后续内容丢失 - 排序后粘贴回去时，原始缩进、换行、注释位置全乱，
/* reset */可能跑到height行中间 - Sublime 的正则引擎不支持条件匹配，无法区分“这是属性”还是“这是 @supports 里的属性”
排序后记得检查 vendor-prefixed 属性的位置
CSS 属性排序工具普遍把带前缀的属性（-moz-appearance、-webkit-box-orient）当普通字符串排，结果常出现在非前缀属性之后，比如：
display: flex; -moz-box-orient: horizontal; -webkit-box-orient: horizontal; box-orient: horizontal;这违反了浏览器兼容性最佳实践——前缀属性应紧挨标准属性，且按前缀顺序排列（-webkit- → -moz- → -ms-）。手动调整或改用支持 prefix-aware 排序的工具（如 VS Code 的 postcss Sorting 扩展）更稳妥。
真正在意兼容性的项目，别依赖 Sublime 自动排序；把排序当成整理收尾动作，而不是编码流程一环。