sass lint 的 color-hex-case 规则强制统一十六进制颜色大小写以避免 git diff 混乱，推荐设为 lower；需通过 .sass-lint.yml 配置文件落地，仅 cli 参数无效；property-sort-order 按语义分组排序，建议用 concentric-css 预设；vs code 集成失败常因插件未绑定 scss 模式或路径配置错误。
为什么 Sass lint 会报 color-hex-case 错误
因为 Sass 默认不强制大小写，但团队协作中 #fff 和 #FFF 混用会让 Git diff 变得混乱，也容易掩盖真实变更。Sass Lint 的 color-hex-case 规则就是干这个的——它要求统一用小写或大写。
常见错误现象：Expected "#FFF" to be "#fff" 或反过来；实际编译完全不受影响，但 CI 会直接失败。
- 推荐设为
lower（小写），和大多数 CSS 工具链（如 Stylelint）默认一致 - 若项目已大量使用大写，可临时设为
upper，但不建议长期维持 - 该规则不影响变量插值，比如
$color: #fff; .a { color: $color; }不触发检查
Sass Lint 配置文件怎么接入项目
不能只靠命令行临时加参数，必须有配置文件落地，否则 IDE 插件、Git Hook、CI 都无法复用同一套规则。
使用场景：VS Code 中装了 scss-lint 插件但没反应？大概率是缺 .sass-lint.yml。
- 根目录下新建
.sass-lint.yml，内容至少包含options:和rules:两层 - 不要用
.sasslintrc或sass-lint.json，Sass Lint 只认.yml后缀且文件名带点 - 运行
npx sass-lint -v确认版本，v1.13+ 才支持color-hex-case等新规则 - 如果用 Webpack，需额外配
sass-lint-webpack-plugin，否则 loader 不读配置
property-sort-order 规则为什么总报错却很难调对
这个规则不是简单按字母排，而是按 CSS 属性语义分组排序（比如 display 在 top 前，background 在 color 前）。一旦顺序错，就会报 Property 'margin' should be before 'padding' 这类提示。
性能影响几乎为零，但兼容性差：旧版 Sass Lint 的内置排序表和新版不一致，升级后可能大面积报错。
- 别手写排序数组，直接用社区维护的
concentric-css预设（在配置里写order: concentric-css） - 允许局部禁用：在某段样式前加
// sass-lint:disable property-sort-order，适合第三方 mixin 输出 - 注意：该规则对嵌套选择器内的属性也生效，
&:hover { color: red; top: 0; }同样要排序
VS Code 里改了代码但 lint 不提醒，是哪里断了
最常被忽略的是插件没绑定到 scss 语言模式，或者用了错误的插件。
典型现象：保存后无任何提示，终端跑 sass-lint 却能报错——说明 CLI 正常，编辑器集成失败。
- 装官方推荐的
glen-84.vscode-sass-lint，别用名字带 “scss” 或 “lint” 但作者不明的插件 - 在 VS Code 设置里搜
sassLint.executablePath，手动指向项目本地的node_modules/.bin/sass-lint - 检查右下角语言模式是否为
SCSS（不是CSS），否则插件根本不会启动 - 重启 VS Code，光重载窗口不够，插件进程可能还卡在旧配置里
规则本身不难配，难的是让所有环节——CLI、CI、编辑器、Webpack——读的是同一个 .sass-lint.yml。路径写错一级、插件版本不匹配、语言模式识别失败，都会导致“规则写了但像没写”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
