根本原因是@import路径错误或未被解析，如路径书写错误、缺少扩展名、相对路径层级不当，导致scss文件未被编译进最终css中。
检查 @import 路径是否正确且被解析
很多样式不生效，根本原因是 Sass 文件里用 @import 引入的依赖根本没被编译进去——比如路径写错、扩展名漏写、或用了不支持的相对路径层级。
- Sass 从 v4.0+ 开始默认禁用无扩展名的
@import，必须写全路径和扩展名，例如：@import "base/_variables.scss";，不能只写@import "base/variables"; - 如果使用 Webpack +
sass-loader，注意它默认不处理.sass文件里的@import（只认.scss），除非显式配置implementation: require('sass')并启用additionalData等兼容逻辑 - VS Code 或命令行编译时，
sass --watch src/main.scss dist/main.css默认以main.scss所在目录为根，所有@import都是相对于该目录解析，不是相对于被 import 的文件
确认 !default 和变量覆盖顺序是否合理
样式“看似写了却没效果”，常因变量被后加载的文件覆盖，尤其在多人协作或引入第三方主题时。
-
$primary-color: #007bff !default;只在变量未定义时生效；一旦前面某处已赋值（哪怕只是$primary-color: null;），后续!default就完全失效 - 确保自定义变量文件在主题/框架变量之后
@import，否则你的$border-radius: 8px可能早于框架中$border-radius: 4px !default被读取，最终用的还是默认值 - 调试技巧：在关键样式块里临时插入
@debug $primary-color;，看终端输出的实际值，比猜更可靠
排查 CSS 特异性（specificity）被意外覆盖
编译出来的 CSS 规则存在，但浏览器开发者工具里显示 strikethrough（删除线），说明被更高特异性的规则干掉了——这和 Sass 编译本身无关，但容易误判为“编译失败”。
- 检查是否无意中嵌套过深，例如：
.card { .header { .title { color: red; } } }编译成.card .header .title，特异性远高于你预期的.title单独选择器 - 警惕
&的副作用：如.btn { &--primary { ... } }生成的是.btn.btn--primary，而如果你本意是独立类名btn--primary，就得写成.btn--primary { ... } - 用浏览器 DevTools 的“Computed”面板点开某条样式，看“Sources”里列出的所有匹配规则，按权重排序，一眼就能定位谁赢了
验证 sourcemap 是否映射错位导致误判
有时候你以为样式没生效，其实是 sourcemap 指向了错误的 Sass 行，让你改了 A 行却以为在调 B 行，反复折腾无效。
- 开启编译 sourcemap 后，检查生成的
.css.map文件是否真实存在、路径可访问（尤其在生产构建中常被忽略） - Webpack 用户注意：
sass-loader的sourceMap选项必须与devtool配置协同，例如devtool: 'source-map'+sassLoaderOptions: { sourceMap: true }，缺一不可 - Chrome DevTools 中右键 CSS 属性 → “Go to definition”，如果跳转到空白行或错误文件，基本可判定 sourcemap 错位，此时应暂时关掉 sourcemap 直接看编译后 CSS 排查
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
