如何修复Sass编译后CSS样式不生效的问题

根本原因是@import路径错误或未被解析，如路径书写错误、缺少扩展名、相对路径层级不当，导致SCSS文件未被编译进最终CSS中。

检查 @import 路径是否正确且被解析

很多样式不生效，根本原因是 Sass 文件里用 @import 引入的依赖根本没被编译进去——比如路径写错、扩展名漏写、或用了不支持的相对路径层级。

1. Sass 从 v4.0+ 开始默认禁用无扩展名的 @import，必须写全路径和扩展名，例如：@import "base/_variables.scss";，不能只写 @import "base/variables";
2. 如果使用 Webpack + sass-loader，注意它默认不处理 .sass 文件里的 @import（只认 .scss），除非显式配置 implementation: require('sass') 并启用 additionalData 等兼容逻辑
3. VS Code 或命令行编译时，sass --watch src/main.scss dist/main.css 默认以 main.scss 所在目录为根，所有 @import 都是相对于该目录解析，不是相对于被 import 的文件

确认 !default 和变量覆盖顺序是否合理

样式“看似写了却没效果”，常因变量被后加载的文件覆盖，尤其在多人协作或引入第三方主题时。

1. $primary-color: #007bff !default; 只在变量未定义时生效；一旦前面某处已赋值（哪怕只是 $primary-color: null;），后续 !default 就完全失效
2. 确保自定义变量文件在主题/框架变量之后 @import，否则你的 $border-radius: 8px 可能早于框架中 $border-radius: 4px !default 被读取，最终用的还是默认值
3. 调试技巧：在关键样式块里临时插入 @debug $primary-color;，看终端输出的实际值，比猜更可靠

排查 CSS 特异性（specificity）被意外覆盖

编译出来的 CSS 规则存在，但浏览器开发者工具里显示 strikethrough（删除线），说明被更高特异性的规则干掉了——这和 Sass 编译本身无关，但容易误判为“编译失败”。

1. 检查是否无意中嵌套过深，例如：.card { .header { .title { color: red; } } } 编译成 .card .header .title，特异性远高于你预期的 .title 单独选择器
2. 警惕 & 的副作用：如 .btn { &--primary { ... } } 生成的是 .btn.btn--primary，而如果你本意是独立类名 btn--primary，就得写成 .btn--primary { ... }
3. 用浏览器 DevTools 的“Computed”面板点开某条样式，看“Sources”里列出的所有匹配规则，按权重排序，一眼就能定位谁赢了

验证 sourcemap 是否映射错位导致误判

有时候你以为样式没生效，其实是 sourcemap 指向了错误的 Sass 行，让你改了 A 行却以为在调 B 行，反复折腾无效。

1. 开启编译 sourcemap 后，检查生成的 .css.map 文件是否真实存在、路径可访问（尤其在生产构建中常被忽略）
2. Webpack 用户注意：sass-loader 的 sourceMap 选项必须与 devtool 配置协同，例如 devtool: 'source-map' + sassLoaderOptions: { sourceMap: true }，缺一不可
3. Chrome DevTools 中右键 CSS 属性 → “Go to definition”，如果跳转到空白行或错误文件，基本可判定 sourcemap 错位，此时应暂时关掉 sourcemap 直接看编译后 CSS 排查

真正卡住人的往往不是语法错误，而是变量作用域、import 解析顺序、CSS 层叠优先级这些隐性链条断在某个环节。动手前先打开浏览器 DevTools 的 Network 和 Elements 面板，确认 CSS 文件是否加载成功、是否有 404、是否有被 disable 的规则——比重编译十次更省时间。