Stylelint

很多项目把代码规范理解成 JS / TS 层的事，样式层却一直在“能写就行”。结果常见的问题会慢慢堆出来：

• 选择器越来越乱
• 重复样式越来越多
• 无效属性没人发现
• SCSS、CSS Modules、Vue SFC 各写各的

Stylelint 的价值，就是把样式层也拉进可执行规范。

Stylelint 更适合管什么

它适合处理这些事：

• 非法 CSS 写法
• 无效属性和值
• 重复声明
• 选择器复杂度
• 命名约束
• 样式文件的组织规则

如果项目里样式已经有一定体量，Stylelint 往往很快就能体现价值。

一个最小起步方式

Stylelint 官方文档给出的思路很直接：

• 先扩展一份合适的共享配置
• 再按项目需要补自定义规则

一个最小配置可以是：

/** @type {import('stylelint').Config} */
export default {
  extends: ['stylelint-config-standard'],
}

然后跑：

stylelint "**/*.css"

前端项目里更常见的配置

多数项目不只 lint 纯 CSS，还会碰到：

• SCSS
• Vue SFC
• CSS Modules
• CSS-in-JS 的一部分场景

一个更常见的配置会像这样：

/** @type {import('stylelint').Config} */
export default {
  extends: ['stylelint-config-standard-scss'],
  overrides: [
    {
      files: ['**/*.{vue,html}'],
      customSyntax: 'postcss-html',
    },
    {
      files: ['**/*.{scss,css}'],
      customSyntax: 'postcss-scss',
    },
  ],
  rules: {
    'color-hex-length': 'short',
    'selector-max-id': 0,
    'declaration-no-important': true,
    'selector-class-pattern': '^[a-z][a-z0-9\-]+$'
  },
}

这份配置更接近真实项目，因为它已经在处理：

• 多种样式文件
• Vue / HTML 容器语法
• 基础命名约束
• !important 这类常见边界

样式层最常见的几类规则

1. 非法写法和拼写问题

这是最值得早点接的一层，因为收益很高，争议很少。

2. 选择器复杂度

例如限制：

• ID 选择器
• 过深嵌套
• 选择器命名模式

这层适合防止样式越写越难维护。

3. !important

很多团队会直接限制或禁止。

因为一旦 !important 滥用，后面样式优先级基本会越来越难收拾。

4. 命名规则

如果团队对 class 命名有约束，例如 kebab-case、BEM 或某种模块化命名，这层可以由 Stylelint 承接。

和 CSS Modules / SCSS 怎么配

CSS Modules

如果项目大量使用 CSS Modules，命名规则通常要稍微放宽，因为有些局部命名不会完全等同于公共类名约束。

SCSS

SCSS 项目更常见的是扩 stylelint-config-standard-scss，再配 postcss-scss 这类语法支持。

Vue SFC

Vue 单文件组件里，如果要 lint <style> 部分，一般会接 postcss-html 这类 custom syntax。

Ignore 也要早点配

常见忽略项：

• dist
• build
• coverage
• 自动生成样式文件
• 某些第三方主题包

可以放在 .stylelintignore，也可以用配置文件里的 ignore 规则处理。

CLI 和脚本怎么接

一个比较常见的脚本配置：

{
  "scripts": {
    "lint:style": "stylelint \"**/*.{css,scss,vue}\"",
    "lint:style:fix": "stylelint \"**/*.{css,scss,vue}\" --fix"
  }
}

本地一般更常用 --fix，CI 更适合只检查不改文件。

编辑器里怎么接

如果团队的样式文件很多，编辑器里直接出诊断会很省时间。和 ESLint 一样，越早看到问题，修起来越轻。

哪些规则别一开始就拉太满

样式层也有类似情况。刚起步时，建议优先：

• 先拦明显错误
• 再接基础约束
• 最后才去管复杂命名和结构性规则

如果一开始就把样式规则上得过细，老项目通常很容易炸出大量历史噪音。

更适合先记住的主线

Stylelint 的价值不是“让 CSS 更严格”，而是：

• 把样式问题前移
• 把样式层也纳入统一协作规范
• 让 CSS / SCSS / Vue 样式不再一直游离在规范链路之外

参考来源

• Stylelint Getting started