必须用 @each 而不是 @for，因为 @each 能同时获取键名（如 "success"）和颜色值，保障类名语义化与可维护性；@for 仅得数字索引，增删颜色后映射错乱，导致 .bg-2 含义不明且易冲突。
直接用 @each 遍历颜色 map，别用 @for 硬套数字索引——类名语义和维护性全靠键名撑着。
为什么必须用 @each 而不是 @for？
颜色辅助类的核心价值是语义化：.text-success 比 .text-1 明确得多。而 @for 只能拿到数字索引，拿不到键名，一旦增删颜色，所有数字映射就全乱了。
常见错误现象：@for $i from 1 through length($colors) 生成一堆 .bg-1、.bg-2，但没人知道 2 对应 warning 还是 info；后续改 $colors 顺序，类名含义就彻底错位。
-
$colors必须定义为 map 类型，例如：$colors: ("primary": #0d6efd, "success": #198754, "warning": #ffc107); -
@each $name, $color in $colors才能同时拿到键（$name）和值（$color），类名拼写才可靠 - 如果误把颜色写成字符串（如
"#198754"），Sass 编译会报错：Invalid CSS: expected color—— 必须用真实颜色类型参与计算
@each 循环里怎么安全生成变体类？
hover、light、dark 这类变体不能塞进同一个 @each 里硬写条件判断，否则逻辑膨胀、难调试、CSS 体积失控。推荐分层处理：
- 基础色循环：
@each $name, $color in $colors { .text-#{$name} { color: $color; } } - 变体单独循环：
@each $name, $color in $colors { .text-#{$name}-hover { color: lighten($color, 10%); } } - 避免对
rgba()直接调用lighten()或darken()—— Sass 不支持，会崩；改用mix($color, white, 80%)或先分离 alpha 再处理 - 文字反色别手写
#fff/#000，用contrast-color($color)更鲁棒
命名空间冲突和类名合法性要注意什么？
直接生成 .bg-red 很可能撞上第三方框架（比如 Bootstrap 的 .bg-danger），覆盖后行为不可预期。纯数字开头的类名（如 .bg-1）虽能编译，但不符合 CSS 类名规范，且无法被 JS querySelector 安全引用。
- 加前缀最稳妥：
.my-bg-#{$name}或.theme-bg-#{$name} - 别拼冗余后缀，
.my-bg-success已足够明确，不用.my-bg-success-base - 若需兼容 IE8+，坚持用
@each编译出静态类；别换成 CSS 自定义属性方案——IE11 以下不支持var(--color)
真正麻烦的不是写循环，而是颜色 map 本身是否干净：重复颜色会让 index() 返回错位索引，非唯一键名会导致覆盖，map-keys() 在 Sass 3.4+ 后顺序不保证——这些细节比语法本身更容易让生成结果出错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
