为什么需要校验 CSS 规则
对于编程语言进行「语法、书写」校验，能有效「归并」不同开发者的「不同风格」，还能检验出一些语法错误。
比如 eslint 就能校验 JS 代码的「鸡肋糟粕」。
对于 CSS 而言，不能算是严格意义的「编程语言」，但是在前端体系中却不能小觑。
CSS 是以描述为主的「样式表」，如果「描述」得「混乱、没有规则」，对于其他开发者一定是一个「定时炸弹 ?『特别是有强迫症的人群 ?』」
CSS 看似简单，想要写出漂亮的 CSS 还是相当困难。CSS 为什么这么难学？ - CSS 不是科学，而是艺术
所以校验 CSS 规则的行动迫在眉睫，立即执行。
团队协作在 CSS 书写遇到的问题
请看以下场景：
小冯：你的 CSS 为什么不把 0.1 写成 .1
小杰：CSS 解析器一样能识别，不好较真好么
小冯：好吧 ?，那为什么你的逗号后面没有空格，我看着很难受啊
小杰：我看着不难受就好
小冯：???，那你能不能不要新建一个空的 CSS 文件啊！！！
…
不论是在社区、MR、平时交流中，相似的场景层出不穷，
这就是因为 CSS 规则不统一，导致的弊端「冰山一角」
CSS 哪些东西需要校验
单纯从代码层面来说，CSS 校验的东西其实蛮少的。
比如：属性顺序、小于 1 的小数要不要去掉 0、选择器之间要不要加空格…
不过要细细的追究，校验的东西还是挺多的，比如 List of rules 列出了好多需要校验的规则。
叮叮叮~~~，有个东西要说一下，CSS 语言本身对「规则」不敏感，几乎是你想怎么写就怎么写，只要合乎「语法」。
怎么校验 CSS 规则
首先得有一个规则，其次开发者得遵守规则。
如何遵守：
提交 「Merge Request」的时候，以「Code Review」的形式「人工校验」。「好蠢啊，费时费力，效果差」
git commit的时候「自动校验」，校验通过才能提交成功「(＾－＾)V 真好~~~」
通过 stylelint 校验 CSS 规则
简单步骤
npm i --save-dev stylelint stylelint-order
增加 stylelint 配置文件
项目根目录添加文件 .stylelintrc 基本配置文件：
{
"extends": "stylelint-config-standard",
"plugins": [],
"rules": {}
}具体的配置文件内容，欢迎参考：点我呀
注：配置文件使用的 CSS 属性排序规则来自 这里
在 package.json 的 scripts 字段中添加相关命令
{
"scripts": {
"lint-css": "stylelint ‘src/**/*.css‘ --fix",
}
}这样就可以手动执行 npm run lint-css 校验 CSS 了。 ‘src/**/*.css‘ 以 blob 语法表示 CSS 文件的路径。 --fix 表示让 stylelint 尽可能的自动修复 CSS 代码「部分规则还是需要抛出错误，开发者手动修复」
安装 lint-staged、husky
npm i --save-dev lint-staged husky
增加 lint-staged 配置文件
项目根目录添加文件 .lintstagedrc 基本配置文件：
{
"src/**/*.css": [
"stylelint --fix",
"git add"
]
}这样就会在执行 git commit 之前会自动以 stylelint --fix 的方式校验 src/**/*.css CSS 文件
stylelint 的更多使用方式
stylelint 不仅仅可以用于项目中，还可以用于编辑器，比如「Sublime Text」，详细使用规则，这里不赘述。 移步阅读
写在最后
虽然有各种各样的工具能「辅佐」开发者工作，注意，是「辅佐」不是「帮助」。
因为开发者自己需要明确「为什么」要这样校验，我们不能被工具「牵着鼻子走」，是我们「命令」工具这样校验。
嗯，这点很重要。
不然别人问这样做的好处，千万不要「一脸茫然」。
·感谢阅读·
