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 会静默跳过编译，最终样式丢失。

CSS婚礼策划服务机构宣传网站模板

CSS婚礼策划服务机构宣传网站模板是一款适合提供婚礼策划和婚庆服务机构宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。

下载

• 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 加一行注释。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！