@each 并不比 @for 更高效，二者编译性能一致，差异在于语义清晰度、可维护性与类型安全；@each 适合结构化数据遍历，@for 适用于纯数值范围。
在 SCSS 中，@each 并不比 @for “更高效”——编译时性能几乎一致，真正差异在于语义清晰度、可维护性与类型安全。盲目选 @each 反而容易因数据结构误用导致样式静默丢失。
为什么@each不是“性能更快”，而是“意图更明确”
@for 是数值范围展开，@each 是集合遍历，两者都发生在编译期，生成的 CSS 行数相同，不存在运行时开销差异。所谓“高效”，实际指：写对一次、改得清楚、查得明白。
-
@for $i from 1 through 5的意图是“生成 5 个编号类”，但若需求变成“生成sm、md、lg三档类”，硬套@for就得额外映射数组或用nth($list, $i)，多一层间接 -
@each $size, $value in $font-sizes直接暴露键值对，变量名自带语义，无需注释说明$i == 2对应哪个尺寸 - 编译器对
@each的类型检查更严格：传入空map或null会跳过整块（不报错），但传入非list/map类型（比如字符串）会直接报错："red" is not a list or map
@each遍历list时常见错误：单变量 vs 双变量写法混淆
传入 list 必须只用一个变量接收元素；传入 map 必须用两个变量（$key, $value），顺序不能颠倒。错写会导致编译失败或值错位。
- 正确遍历
list：@each $color in (red, green, blue) { .bg-#{$color} { background: $color; } } - 错误写法：
@each $key, $value in (red, green, blue)→ 报错：Invalid syntax for @each: expected comma - 正确遍历
map：@each $name, $size in (sm: 12px, lg: 24px) - 错误写法：
@each $size, $name in $map→$size拿到的是 key（"sm"），$name拿到的是 value（12px），语义全反
@for处理非数值边界时极易崩溃
@for 要求起始值和结束值必须是数字，且不能带单位。一旦变量未定义、为空或含单位（如 1200px），编译直接中断。
立即学习“前端免费学习笔记（深入）”；
- 错误：
@for $i from $min to $max，而$min是null→ 报错："$min" is not a number - 错误：
@for $i from 1 to $breakpoint，而$breakpoint: 1200px→ 报错：Invalid null operation: "1200px" times "1"（后续计算单位乘法时炸） - 安全做法：用
unitless($breakpoint)剥离单位，或提前断言：@if type-of($min) == number and $min != null -
@each则无此问题——它不关心数值，只认结构，map里存1200px或"xl"都能照常遍历
嵌套结构下@each必须分层解构，@for无法替代
当 map 的 value 本身是嵌套结构（例如颜色组、断点配置），@each 可自然分层，@for 则需手动索引 + 类型判断，极易出错。
- 示例数据：
$themes: (light: (bg: #fff, text: #333), dark: (bg: #111, text: #eee)); - 用
@each安全解构：@each $theme-name, $theme-map in $themes { @each $prop, $val in $theme-map { .#{$theme-name}-#{$prop} { color: $val; } } } - 用
@for实现等效逻辑：需先length($themes)得长度，再nth($themes, $i)取项，再判断该项是否为map，再二次遍历——代码膨胀、可读性差、易漏@if判断 - 更关键的是：
nth($themes, 1)返回的是light (bg: #fff, text: #333)这个 pair，不是纯 map，直接@each会报错，必须先map-keys提取再处理
真正该警惕的不是性能，而是“用 @for 硬扛语义场景”：当你发现自己在循环里反复 nth、index、type-of 判断时，大概率该换 @each 了。而反过来，若只是生成 .col-1 到 .col-12 这类纯序号类，@for 更直白，也更难写错。
