核心思路是通过Stylelint与ESLint协同实现CSS代码规范，利用Stylelint处理CSS/SCSS文件，ESLint通过独立脚本或插件集成其检查，确保团队代码风格统一，提升可读性、可维护性，减少错误。
在ESLint中规范CSS代码，核心思路其实不是让ESLint直接去“理解”和“校验”CSS，而是利用它强大的生态系统，将专门的CSS代码规范工具（比如Stylelint）集成进来。这样，我们就能在同一个开发流程和报告机制下，实现JavaScript和CSS代码的一致性管理。说白了，ESLint在这里更像一个协调者，而不是全能的裁判。
解决方案
要确保样式代码的一致性，最直接且推荐的方案是引入Stylelint，并将其与ESLint的工作流结合。这通常意味着你会在项目中安装Stylelint，配置其规则，然后通过构建工具、IDE插件或者Git Hook来触发它的检查。对于那些在JavaScript文件中编写的CSS（比如CSS-in-JS），ESLint有一些特定的插件可以处理，但对于独立的
.css,
.scss,
.less文件，Stylelint是当之无愧的主角。
CSS代码规范的重要性是什么？
我个人觉得，写CSS最头疼的就是，项目一大，团队成员一多，每个人写CSS的习惯、缩进、命名、属性顺序都可能迥异。结果就是，代码风格千奇百怪，维护起来简直是灾难，改个样式都得小心翼0，生怕影响到其他地方。这时候，一个统一的规范就显得尤为重要了。它能强制大家遵守一套约定，比如颜色值必须小写、单位前不能有空格、属性必须按字母顺序排列等等。这不仅仅是“好看”的问题，更是为了提高代码的可读性、可维护性，减少潜在的bug。想象一下，一个新同事加入项目，他不需要花大量时间去适应各种奇怪的CSS写法，直接按照规范来就行，效率一下就上来了。而且，很多时候我们写CSS会犯一些低级错误，比如属性名拼写错误、无效的单位，这些规范工具都能第一时间帮你揪出来，省去了很多调试的麻烦。
Stylelint如何与ESLint协同工作？
这事儿吧，说起来简单，做起来也真不难，但效果那是杠杠的。ESLint天生就是管JavaScript/TypeScript的，它对CSS并不感冒。所以，我们得请出专门的CSS管家——Stylelint。它们俩的协同工作方式，主要有以下几种，你可以根据项目情况选择：
立即学习“前端免费学习笔记（深入）”；
-
独立运行Stylelint（推荐）：这是最常见也最清晰的方式。你安装Stylelint和其配置（比如
stylelint-config-standard
），在package.json
里加一个lint:css
脚本，比如"stylelint '**/*.{css,scss}'"。然后在你的CI/CD流程或者Git Hook（用Husky和lint-staged）里分别跑ESLint和Stylelint。这种方式职责分明，各自做各自擅长的事。// package.json { "scripts": { "lint:js": "eslint . --ext .js,.jsx,.ts,.tsx", "lint:css": "stylelint '**/*.{css,scss}'", "lint": "npm run lint:js && npm run lint:css" }, "devDependencies": { "eslint": "^8.0.0", "stylelint": "^15.0.0", "stylelint-config-standard": "^34.0.0", "stylelint-scss": "^5.0.0", "husky": "^8.0.0", "lint-staged": "^13.0.0" }, "lint-staged": { "*.{js,jsx,ts,tsx}": "eslint --fix", "*.{css,scss}": "stylelint --fix" } }// .stylelintrc.json { "extends": [ "stylelint-config-standard", "stylelint-scss/recommended" ], "rules": { "indentation": 2, "color-hex-case": "lower", "selector-max-id": 0, "declaration-block-no-redundant-longhand-properties": true } } -
通过ESLint插件集成Stylelint：如果你实在想把所有报告都统一到ESLint的输出中，可以使用
eslint-plugin-stylelint
这个插件。它本质上是在ESLint的流程中调用了Stylelint。但说实话，我个人觉得这种方式有点多此一举，因为Stylelint本身就能很好地输出报告，而且多一层封装可能会带来一些额外的配置复杂性或性能开销。// .eslintrc.js (示例，不推荐作为主要方案) module.exports = { // ...其他ESLint配置 plugins: [ "stylelint" ], rules: { "stylelint/stylelint": ["error", { "configFile": "./.stylelintrc.json" // 指定Stylelint配置文件 }] } }; 针对CSS-in-JS：如果你用的是React的Styled Components或者Emotion这类CSS-in-JS库，那么ESLint确实有直接的插件可以处理。比如
eslint-plugin-styled-components
或者eslint-plugin-emotion
。这些插件能理解JS模板字符串里的CSS语法，并进行基本的校验。但请注意，它们通常不会像Stylelint那样提供非常细致的CSS规则检查，更多是语法层面的。
在我看来，第一种独立运行的方式最干净利落。各自的工具处理各自的领域，通过Git Hook或者CI/CD来统一触发，这样既能保证效率，又能保持配置的简洁性。
Stylelint常用配置有哪些？
要让Stylelint真正发挥作用，配置是关键。一个好的配置能让你省心不少。这里我列举一些我个人觉得非常实用，能显著提升代码一致性的常用配置：
-
基础配置集 (
extends
)：stylelint-config-standard
: 这是Stylelint官方推荐的标准配置，包含了大量通用的CSS最佳实践。它能帮你处理很多基础的规范问题，比如缩进、空格、括号等。stylelint-config-recess-order
: 如果你对CSS属性的顺序有要求（比如按字母顺序、或特定的逻辑顺序），这个配置就非常有用。它能强制所有CSS块内的属性都按照预设的顺序排列，大大提升代码的可读性。stylelint-scss
: 如果你的项目使用了SCSS，那这个插件是必不可少的。它提供了许多针对SCSS语法的规则，比如变量定义、混合器使用、嵌套深度等。
-
自定义规则 (
rules
)：在extends
的基础上，你还可以根据团队的具体需求添加或覆盖规则。// .stylelintrc.json 示例 { "extends": [ "stylelint-config-standard", "stylelint-config-recess-order", "stylelint-scss/recommended" ], "rules": { // 缩进：强制使用2个空格缩进，这是我个人偏好，也是很多项目的主流 "indentation": 2, // 颜色值大小写：强制使用小写，统一性强 "color-hex-case": "lower", // 选择器ID最大数量：通常建议避免使用ID选择器，设为0能强制你思考更好的方案 "selector-max-id": 0, // 属性值单位：禁止未知单位，避免拼写错误 "unit-no-unknown": true, // 属性名：禁止未知属性名，同样是避免拼写错误 "property-no-unknown": true, // 声明块单行最大声明数：限制一行最多一个声明，提高可读性 "declaration-block-single-line-max-declarations": 1, // 声明块末尾分号：强制要求分号，避免潜在问题 "declaration-block-trailing-semicolon": "always", // 伪类选择器：强制小写 "selector-pseudo-class-case": "lower", // 伪元素选择器：强制小写 "selector-pseudo-element-case": "lower", // 字符串：强制使用单引号 "string-quotes": "single", // 字体系列：强制使用通用字体族 "font-family-no-missing-generic-family-keyword": true, // 禁止使用重要的声明：除非特殊情况，否则 `!important` 应该避免 "declaration-no-important": true, // 媒体查询括号内的空格：统一格式 "media-feature-parentheses-space-inside": "never", // SCSS特定的规则，例如变量名格式 "scss/dollar-variable-pattern": "^[a-z]+([a-z0-9-]+[a-z0-9]+)?$" } }
这些规则的组合，基本上就能覆盖到日常开发中大部分的规范需求。通过这种方式，团队成员在提交代码前，就能自动检查并修正不符合规范的样式，大大减少了代码审查时关于风格的争论，让大家能更专注于业务逻辑本身。
如何处理Stylelint的例外情况和高级用法？
实际项目中，总会遇到一些特殊情况，不能一刀切。比如，一些老旧代码你不想立即重构，或者某个特定场景确实需要打破常规。Stylelint也考虑到了这些：
-
禁用规则：你可以通过注释来临时禁用Stylelint的规则。
/* stylelint-disable */
和/* stylelint-enable */
：禁用一个区域的所有规则。/* stylelint-disable-line */
：禁用当前行的所有规则。/* stylelint-disable-next-line */
：禁用下一行的所有规则。- 你也可以指定禁用特定的规则，比如
/* stylelint-disable color-hex-case */
。
/* stylelint-disable-next-line indentation */ .legacy-component { margin: 0; padding: 10px; /* 这行缩进不规范，但我们暂时不想改 */ } /* stylelint-disable color-hex-case */ .special-color { color: #FFF; /* 这里故意用大写 */ } /* stylelint-enable color-hex-case */ -
忽略文件/目录：在你的
.stylelintrc.json
中，可以使用ignoreFiles
字段来忽略特定的文件或目录，比如第三方库的CSS文件或者你不想被Stylelint检查的旧项目部分。// .stylelintrc.json { // ...其他配置 "ignoreFiles": [ "**/node_modules/**", "src/legacy-styles/**/*.css" ] } 与IDE集成：大部分现代IDE（比如VS Code）都有Stylelint插件。安装后，它们能在你编码时实时给出反馈，甚至自动修复一些简单的问题（通过
--fix
参数），这比等到提交代码时才发现问题要高效得多。与Prettier协同：Stylelint和Prettier是好搭档，但它们解决的问题略有不同。Stylelint关注的是“代码规范”，比如属性顺序、禁止使用
!important
；Prettier则专注于“代码格式化”，比如缩进、空格、换行。我的做法是，先用Prettier格式化代码（prettier --write
），然后再用Stylelint检查规范（stylelint --fix
）。这样，Prettier能帮你搞定大部分的格式问题，Stylelint则确保代码符合更深层次的规范。两者结合，能让你的代码既整洁又规范。记住，它们是互补的，不是替代关系。
