order/properties-order 规则必须手动配置，因其属于 @stylistic/stylelint-plugin 插件功能而非 Stylelint 核心规则，需安装插件、显式启用并提供顺序数组或预设；旧版 stylelint-order 已归档，推荐迁移至 @stylistic 生态。
为什么 order/properties-order 规则必须手动配置？
Stylelint 默认不启用任何属性排序规则，order/properties-order 属于 @stylistic/stylelint-plugin（或旧版 stylelint-order）插件功能，不是核心规则。不显式声明，就等于没生效。
- 插件需先安装：
npm install -D @stylistic/stylelint-plugin - 配置中要显式启用该规则，并提供具体顺序数组或预设
- 若用的是旧版
stylelint-order，注意它已归档，新版推荐迁移至@stylistic统一生态
怎么写一个既合理又可维护的属性顺序数组？
硬编码全部 100+ CSS 属性不现实，也难同步更新。推荐按语义分组 + 使用插件提供的预设作为基线，再微调：
- 用
plugin-order/configs/recommended或plugin-order/configs/styled-components起手（取决于是否用 CSS-in-JS） - 在其基础上调整局部顺序，比如把
content提前到伪元素相关属性区，或把transition统一放在动画组末尾 - 避免把
display和visibility拆太远——它们同属“是否渲染”语义层，放一起更符合直觉 - 不要为兼容性加
-webkit-前缀单独设条目；现代项目应由 Autoprefixer 处理，Stylelint 只管标准属性
示例片段（精简）：
[ "appearance", "display", "visibility", "position", "top", "right", "bottom", "left", "z-index", "flex", "flex-grow", "flex-shrink", "flex-basis", "order", "align-self" ]
团队落地时最常踩的三个坑
-
order/properties-order 对自定义属性（--my-color）默认不校验，需显式在配置中用 customProperties 选项开启，否则变量混在中间也不会报错
- 使用
at-rule-nested（如 @media 内嵌规则）时，子选择器里的属性排序不会自动继承父级顺序，得单独配 severity: "error" 并检查嵌套层级
- VS Code 中保存即修复（
stylelint.autoFixOnSave）对排序类规则支持不稳定，部分版本会跳过或乱序；建议改用 eslint --fix 方式统一跑，或确认 Stylelint 版本 ≥ 16.2 且插件匹配
要不要用 alphabetical 模式代替语义分组？
order/properties-order 对自定义属性（--my-color）默认不校验，需显式在配置中用 customProperties 选项开启，否则变量混在中间也不会报错at-rule-nested（如 @media 内嵌规则）时，子选择器里的属性排序不会自动继承父级顺序，得单独配 severity: "error" 并检查嵌套层级stylelint.autoFixOnSave）对排序类规则支持不稳定，部分版本会跳过或乱序；建议改用 eslint --fix 方式统一跑，或确认 Stylelint 版本 ≥ 16.2 且插件匹配alphabetical 模式代替语义分组？可以，但代价明显：
立即学习“前端免费学习笔记（深入）”；
-
order/properties-alphabetical-order确实省事，所有属性按字母排，规则配置极简 - 但它割裂了开发直觉——比如
margin和margin-top被拆开，transform和transition不挨着，调试时扫一眼很难定位关联样式 - 更关键的是，它无法表达设计意图（例如“布局优先、装饰靠后”），长期看反而增加认知负担
真正难的不是定顺序，而是让所有人接受同一套分组逻辑。建议第一次对齐时，拿真实组件 CSS 截图投票，比纯文档更有说服力。
