嵌套应限于父子/状态依赖场景，深度超3层需拆分；map取值key须加引号并校验存在；@mixin生成样式块，@function返回计算值；@extend易致冗余选择器，现代项目宜用工具类替代。
嵌套规则写多了反而让CSS更难维护？
嵌套本身不坏，但 Sass 的 @nest（或老式缩进嵌套）容易诱使开发者写出过深、耦合过紧的选择器。比如三层以上嵌套后，.header .nav .item .link:hover 这种选择器既难调试，又极易因 DOM 结构微调而失效。
真正该嵌套的，是**有明确父子/状态依赖关系**的场景：伪类、伪元素、媒体查询、属性选择器。其他情况优先用 BEM 式命名或单独类名。
- 媒体查询必须嵌套——
@media (max-width: 768px)放在组件内部最直观 -
:hover、::before这类状态/装饰性样式适合嵌套，语义清晰 - 避免嵌套两个不相关的父类，比如
.card里再嵌.button——它们应各自独立 - 深度超过 3 层时，立刻停下来问：是不是该拆成新组件或提取混合宏？
Sass 变量和 map-get 搭配颜色系统时为什么总报错？
常见错误是把颜色定义写成 $colors: (primary: #007bff)，然后直接 color: map-get($colors, primary) ——这里 primary 缺少引号，Sass 会把它当变量而非 key，报 Undefined variable。
更隐蔽的问题是嵌套 map：比如 $theme: (light: (text: #333))，取值必须写成 map-get(map-get($theme, light), text)，漏一层就返回 null，编译不报错但 CSS 生效失败。
立即学习“前端免费学习笔记（深入）”；
- 所有 map 的 key 必须加引号：
map-get($colors, "primary") - 用
map-has-key($map, "key")先校验存在性，避免静默失败 - 别在
@each循环里直接解构深层 map，先map-get拿到子 map 再操作 - 考虑用
!default给基础 map 设默认值，防止被空覆盖
@mixin 和 @function 到底该选哪个？
核心区别就一条：是否返回 CSS 声明块。需要生成一整段样式（比如 Flex 布局重置、响应式字体）用 @mixin；需要计算值（比如根据色值生成对比色、算出 rem 值）必须用 @function。
混用时最容易踩坑的是传参类型。比如写了个 @function px-to-rem($px)，但如果传入 16px（带单位）而非 16（纯数字），函数内部做除法就会报 Incompatible units。
-
@mixin适合封装重复的声明组合，如@include flex-center -
@function返回值只能是 Sass 数据类型（数字、字符串、列表等），不能返回选择器或声明块 - 函数参数建议加类型检查：
@if type-of($px) != number就 warn - 别在 mixin 里调用未定义的 function——Sass 是顺序解析，function 必须先声明
编译后 CSS 体积暴增，是不是嵌套和 @extend 惹的祸？
是。Sass 的 @extend 在编译时会做选择器合并，遇到复杂继承链（比如 A @extend B，B @extend C），最终可能生成几十个组合选择器。嵌套 + @extend 更危险，比如 .btn {@extend %reset;} 在 .modal 下嵌套，就会产出 .modal .btn, .modal %reset 这类无效代码。
现代项目中，@extend 已基本被实用工具类（utility classes）或 CSS 自定义属性替代。它只适合极少数场景：抽象纯视觉重置（如 %clearfix）、或严格控制输出选择器数量的遗留系统。
- 禁用跨模块
@extend——不同文件间的 extend 会让依赖关系不可见 - 用
@debug查看编译前的 AST，确认 extend 是否触发了意外合并 - Webpack/Vite 中开启
sassOptions: { outputStyle: 'compressed' }只能压体积，压不住冗余选择器 - 真正省体积靠的是原子化：用
class="d-flex justify-content-center"替代自定义 block mixin
嵌套层级、map 深度、extend 范围——这些不是语法问题，是架构选择。写得越“顺手”，越要警惕编译结果是否还符合你对 CSS 的原始预期。
