必须在编译后立即校验，否则CI中“编译成功但CSS有错”会静默通过、上线后样式崩塌；需用postcss+stylelint对生成的CSS做静态检查，lessc仅转换语法，不验证CSS合法性，如color:#zzz;或display:flexbox;等错误无法拦截。
必须在编译后立即校验，否则 CI 里“编译成功但 CSS 有错”会静默通过，上线后样式崩塌。
用 postcss + stylelint 做编译后 CSS 静态检查
Less 编译器（lessc）只管语法转换，不验证 CSS 合法性。比如 color: #zzz;、display: flexbox; 这类错误，lessc 照样输出，浏览器运行时才报错。所以得在生成 CSS 后加一层校验。
推荐组合：postcss 负责解析 CSS AST，stylelint 负责规则检查——它能定位到原始 Less 文件的行号（前提是编译时开了 source map）。
- Less 编译命令必须带
--source-map：否则stylelint只能报 CSS 行号，无法回溯到.less源码 - CI 脚本中先执行
lessc src/styles.less --source-map > dist/styles.css，再跑npx stylelint dist/styles.css - 用
stylelint的no-invalid-position-at-import-rule、color-no-invalid-hex等规则覆盖基础合法性 - 避免用
stylelint --fix自动修复——CI 是门禁，不是编辑器，修复应由开发者手动完成
为什么不能只靠 lessc --lint？
lessc --lint 只检查 Less 语法（比如变量未定义、括号不匹配），对最终生成的 CSS 内容完全不感知。它甚至允许你写 @media (min-width: 768px { 这种漏掉右括号的 Less，只要嵌套结构没破，就通过。
-
lessc --lint不校验单位缺失（margin: 10;）、颜色非法（background: rgb(256, 0, 0);）、属性拼错（tex-align:） - 它也不识别浏览器兼容性问题，比如
gap在旧版 Safari 中无效，lessc完全不管 - 真正要拦截的是“能编译成功但会导致渲染异常”的 CSS，这必须靠 CSS 层面的扫描工具
集成进 CI 流程的关键细节
校验步骤必须阻断式执行，失败即 exit 1，且日志要带上下文。
- 在 GitHub Actions 中，把
stylelint放在build步骤之后、deploy之前，用run: npx stylelint "dist/**/*.css" --max-warnings 0强制零警告 - GitLab CI 中，加
allow_failure: false并配合artifacts: [dist/**/*.css]，方便排查时下载出问题的文件 - 若项目用了
postcss插件链（如autoprefixer），确保stylelint在其之后运行——否则会误报前缀缺失类问题 - 注意路径权限：Docker CI 镜像中若
dist/目录是只读的，stylelint会因无法写缓存而报错，加--cache-location /tmp/.stylelintcache绕过
最容易被忽略的是 source map 映射链：Less → CSS → stylelint 报错行号，三者必须对齐。本地能定位，CI 里却只报 dist/styles.css:42:15，大概率是 lessc 没传 --source-map 或路径写错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
