CSS写起来门槛不高，但要写得规范、干净却不容易。项目迭代几轮之后，样式表里往往充斥着重复声明、未使用的类名、写法不一致的属性顺序，维护成本越来越高。CSSLint正是为解决这类问题而生的一款静态检查工具，它由Nicole Sullivan和Nicholas Zakas开发，能够在不运行代码的情况下扫描CSS文件，找出语法错误和风格隐患。这篇文章就来详细聊聊CSSLint的工作机制、具体用法，以及如何用它建立一套可持续执行的代码规范。
CSSLint能检查出哪些问题
CSSLint内置了二十多条检查规则，大体可以分成两类：一类是错误类，比如语法拼写错误、大括号不闭合、属性名写错；另一类是警告类，主要针对代码质量和潜在的性能问题。理解这些规则的作用，是合理配置工具的前提。
比较典型的检查项包括：检测相邻的重复属性（比如同一个选择器里写了两次color）、查找空的规则块、识别重复定义的样式规则、检查使用了!important的声明、提示box-sizing的浏览器兼容性问题、发现ID选择器与类选择器混用导致的优先级复杂度上升等。这些规则背后其实反映了一套CSS最佳实践，例如尽量避免ID选择器、控制选择器层级深度、减少全局样式污染。
需要注意的是，有些规则属于强约束，有些则更像是建议。比如“禁止相邻重复属性”几乎所有人都应该遵守，而“不要使用ID选择器”在某些老项目里未必现实。所以CSSLint支持按需开关规则，这点后面会详细介绍。
CSSLint的安装与基本使用
CSSLint提供了多种使用方式，最直接的是通过npm全局安装，然后在命令行调用。安装命令如下：
npm install -g csslint
安装完成后，可以对单个文件或整个目录进行检查：
# 检查单个文件 csslint style.css # 检查整个目录下的所有CSS文件 csslint css/ # 以特定格式输出结果，方便集成到CI环境 csslint --format=json style.css
执行后，终端会输出检查结果，包括出错的文件、行号、规则名称和问题描述。例如下面这种输出表示在style.css的第12行存在重复定义的规则：
style.css 1: warning at line 12, col 1 Duplicate rule selectors can be merged. Rule: duplicate-properties
如果想把CSSLint集成到Node项目中，也可以作为本地依赖安装，并通过package.json的scripts字段配置快捷命令，例如"lint:css": "csslint css/"，之后执行npm run lint:css即可触发检查。
如何配置规则以匹配团队规范
直接使用默认规则往往会产生大量不符合团队预期的警告，因此CSSLint支持通过.csslintrc配置文件自定义规则开关。这个文件可以放在项目根目录，支持JSON格式，语法很简单，规则名对应true或false。
一个典型的配置文件如下：
{
"important": false,
"ids": false,
"duplicate-properties": true,
"empty-rules": true,
"box-sizing": true,
"overqualified-elements": true,
"shorthand": true,
"floats": false
}上面这份配置中，关闭了important和ids这两条规则，因为有些遗留项目确实离不开ID选择器；同时保留了重复属性检查、空规则检查和缩写属性建议。配置文件的存在让CSSLint的行为可以被版本控制，团队成员拉取代码后无需额外设置就能保持一致的检查标准，这是规范化流程里非常关键的一环。
除了配置文件，命令行也支持用--rules参数临时指定规则，适合做一次性检查或调试配置。此外CSSLint还提供了ignore参数，可以按行或者按文件忽略特定警告，例如在某个无法避免的hack代码上方添加注释/* csslint ignore:start */，就能跳过这一段的检查，避免误报干扰正常开发。
把CSSLint接入构建与提交流程
单独在命令行手动执行检查，很容易因为遗忘而流于形式。真正让代码规范落地的做法，是把CSSLint嵌入到自动化流程中，常见的接入点有两个：构建环节和代码提交环节。
如果项目使用Gulp作为构建工具，可以配合gulp-csslint插件：
const gulp = require('gulp');
const csslint = require('gulp-csslint');
gulp.task('lint-css', function() {
return gulp.src('css/**/*.css')
.pipe(csslint('.csslintrc'))
.pipe(csslint.formatter())
.pipe(csslint.failFormatter());
});在提交环节，可以借助Git的pre-commit钩子，配合husky或pre-commit这类工具，在每次git commit之前自动跑一遍CSS检查，发现问题就中断提交并给出提示。这样能保证进入仓库的代码始终符合规范，问题在最早阶段就被拦截，修复成本最低。
对于持续集成环境，CSSLint支持多种输出格式，包括checkstyle、junit等，可以把检查结果直接汇总到CI平台的报告页面中，方便追踪规范执行情况。通过这种层层设防的方式，代码规范就不再依赖口头约定，而变成了流程中的硬性门槛。
CSSLint的局限性以及替代方案
说了这么多优点，也要客观看待CSSLint的不足。它的部分规则带有较明显的主观色彩，比如“不要用float布局”在现代多列布局方案下虽然合理，但对旧项目并不友好；工具本身的更新频率也不高，对新出现的CSS特性支持有限，比如一些较新的属性可能被误报为未知属性。
目前社区中更活跃的选择是Stylelint，它支持PostCSS生态，规则库更丰富，可扩展性也更强，支持自动修复部分问题。如果你的项目是新启动的，优先考虑Stylelint通常是更好的选择。但如果团队已经在使用CSSLint，或者需要一个轻量、零配置门槛的工具快速接入老项目，CSSLint依然是够用的。
无论选择哪款工具，核心思路都是一致的：先定义规则，再让规则自动化执行，最后通过流程保障规则的持续性。工具本身只是手段，让团队写出一致、可维护的CSS代码才是最终目的。从CSSLint入手理解这套流程，再迁移到其他工具也会非常顺畅。