Sass缩进语法（.sass）降低可读性，因空格不可见易错位、嵌套深时难辨层级、编辑器缩进不一致致编译失败、Git diff无法识别结构变化；需严格控层、统一2空格、禁用Tab、慎用@extend；工具链兼容成本高，仅适合无协作的极简原型。
为什么 Sass 缩进语法（.sass）反而让 CSS 更难读
它不提升可读性，反而在多数团队协作场景中降低可读性。缩进语法省略了大括号和分号，靠空格层级表达嵌套关系，但空格不可见、易错位、难对齐，尤其在混合媒体查询、伪类、多层嵌套时，一不小心就破层级。
-
@media块里嵌&:hover再套&::before，缩进 4 层后，肉眼很难快速判断哪条规则属于哪个父级 - 复制粘贴或编辑器缩进设置不一致（比如 2 空格 vs 4 空格），会导致编译报错
Invalid CSS after "...": expected "{", was "color: red;" - Git diff 几乎无法识别结构变化——删掉一行缩进，可能整块样式失效，但 diff 只显示“空格数量变了”
.sass 文件里怎么安全地写嵌套规则
能不用就不用；如果必须用，得把嵌套控制在 3 层以内，并且每层都加注释说明作用域边界。
- 避免在
@media内部再嵌&:focus-within这类复合伪类，改用扁平写法：.card__header@media (min-width: 768px)拆成独立选择器 - 所有缩进统一用 2 个空格，禁止 Tab；编辑器需配置保存时自动 trim 行尾空格，否则
- 嵌套中出现
@extend时，必须紧贴上一行末尾写，不能换行——&.is-active@extend %button-base是合法的，换行就报错
从 .scss 切到 .sass 有哪些隐藏兼容成本
不是语法转换问题，而是工具链和人习惯的断层。主流构建工具（Vite、Webpack）默认只配了 sass（即 .scss 解析器），直接改后缀为 .sass 会静默跳过编译，最终样式丢失。
- Vite 中需显式配置
css.preprocessorOptions.sass的indentedSyntax: true，漏掉这行，style.sass就当普通文本处理 - VS Code 的 Sass 插件默认只给
.scss提供语法高亮和 Emmet 支持，.sass文件里敲df不会展开display: flex - 已有
@import链路（如@import "base/variables"）必须全部改成无扩展名写法，且被导入文件也得是.sass后缀，否则编译中断
什么时候真该用 .sass 而不是 .scss
几乎只有两种情况：老项目已全量使用且维护者熟悉缩进规则；或者你写的是极简原型，单文件、无协作、不进 Git —— 比如临时搭个静态 landing page，手写 30 行样式，图快。
立即学习“前端免费学习笔记（深入）”；
- 只要涉及 CSS 变量（
--color-primary）、自定义属性计算、或需要和 JS 动态注入样式对接，一律用.scss——.sass对:的敏感会让var(--color-primary)里的冒号被误判为声明开始 - 想用
@use模块系统？不行。@use只支持.scss；.sass只能用过时的@import，没有作用域隔离 - CI/CD 流水线里没装 Ruby Sass（而只装了 Dart Sass），
.sass文件直接编译失败，错误信息是File not found: "_mixins.sass"，实际是解析器压根没加载
缩进语法不是“更高级的写法”，它只是 Sass 早期为适配 Haml 用户做的妥协。现在真正影响可读性的，从来不是大括号多不多，而是嵌套深度、命名一致性、以及是否有人愿意花 3 秒给 .btn--secondary 加一行注释。
