浏览器控制台出现“CSS parsing error”时，应忽略报错行号，向上排查3–5行，重点检查未闭合的{、}后隐藏字符（空格/逗号）、@use前置空行或BOM等；临时注释可疑规则可快速定位污染源。
浏览器控制台里看到“CSS parsing error”怎么办
直接看控制台报错行号基本没用——它只告诉你“解析失败”，但真凶往往藏在前面几行。常见错误位置：某个 { 没闭合、某个 } 后面多了逗号或空格、@use 前有空行或 BOM。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Console 标签页，找带
CSS parsing error或Invalid CSS after的红字警告 - 别信报错行号，往上翻 3–5 行，重点盯每个
}后面有没有隐藏字符（VS Code 按Ctrl+Shift+P→Toggle Render Whitespace） - 临时把疑似出问题的规则块（比如
.links）整段注释掉，看其他样式是否恢复——能快速锁定污染源 - 检查 HTML 中
<link rel="stylesheet">路径是否 404，有时 404 会伪装成语法错误
VS Code 里样式不标红、保存也不修复
Stylelint 插件只是个开关，真正干活的是项目里的 stylelint 包和配置文件。三件事缺一不可：配置文件存在、插件启用、语言模式绑对。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确认项目根目录有
.stylelintrc.json或stylelint.config.js；没有就运行npx stylelint --init生成一个基础版 - 检查 VS Code 设置里
stylelint.enable是否为true（默认是false） - 如果是
.module.scss文件，settings.json里必须加："stylelint.validate": ["css", "scss", "less"]，且右下角语言模式要手动选成小写的scss，不是SCSS - 关掉
editor.formatOnSave或把 Prettier 排除掉——它会抢在 Stylelint 前格式化，而 Prettier 不认识@layer和自定义属性，直接跳过
为什么改了一个 {，整个导航栏都失效了
CSS 解析器是单次、自上而下的线性扫描。一个 { 没配对，或 } 后多一个逗号，就会让解析器当场放弃当前规则，并跳过其后所有有效声明——哪怕那些规则本身完全正确。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 错误越靠前，影响越大。如果
.links在文件顶部，它出错就可能导致.topnav a完全不生效 - 浏览器 Elements 面板里，如果某条规则显示为灰色或带删除线，大概率是被前面的语法错误“连坐”了
-
top: 10这种没单位的写法虽不报错，但整条声明会被忽略；color: #ffffe6;后面多一个{才是致命伤 - 用 W3C CSS Validator 线上校验（https://jigsaw.w3.org/css-validator/），它比浏览器更严格，能暴露隐藏问题
SCSS 编译后 CSS 为空，怎么查
不是 CSS 写错了，是 Sass 根本没跑起来。Dart Sass 对 @use 位置极其敏感，也对 } 后的非法字符零容忍。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
@use必须是文件第一个非空、非注释行；前面有空行、BOM、中文注释都会让它静默退出 - 路径不能带扩展名和下划线：
@use "src/styles/variables"✅，@use "src/styles/_variables.scss"❌ - 全局搜索
},或}（} 后跟空格），尤其注意 Vue 单文件组件<style lang="scss">末尾、嵌套块结尾、&--modifier后面 - 文件保存为
UTF-8 without BOM；路径不能含中文；@charset "UTF-8";必须是第一行第一个字符
@use 之前（比如 BOM），整个文件就不解析；} 后的非法字符可能藏在文件末尾，编辑器默认不显示，不开空白字符渲染根本看不见。 
