@each 适合批量生成结构一致、仅变量值变化的选择器，如主题色、尺寸类、状态修饰符；它不适用于逻辑判断或嵌套关系推导，且需固定键值对、无条件分支、不依赖 dom 或动态计算。
直接说结论：@each 适合批量生成结构一致、仅变量值变化的选择器，比如主题色、尺寸类、状态修饰符；但它不能替代逻辑判断或嵌套关系推导，硬套反而让代码更难维护。
什么时候该用 @each，而不是手写或 JS 生成？
适用场景很明确：你有一组固定键值对（比如颜色名和十六进制值），且每个都要映射成独立的 CSS 类，没有条件分支、不依赖 DOM 结构、也不需要动态计算。
- ✅ 合适：生成
.text-primary、.bg-warning、.border-danger这类工具类 - ❌ 不合适：根据屏幕宽度决定是否加
hover，或某个状态只在特定组件中生效 - ⚠️ 风险点：如果键名来自外部配置（如 JSON 文件导入），Sass 无法在编译期校验键是否存在，出错时只报
Invalid CSS，定位困难
@each 基本写法与常见错误
最简形式是 @each $key, $value in $map，但很多人漏掉逗号或混淆变量作用域。
- 必须写逗号：
@each $name, $color in $theme-colors—— 少逗号会报Invalid CSS after "$name": expected "in", was "," - 变量名不能重复：外层已定义
$color，循环内再用$color会覆盖，导致后续逻辑错乱 - 嵌套时注意选择器拼接：用
#{$name}而不是#{$name}（后者会被解析为 ID 选择器，不是插值）
@each $name, $color in (primary: #007bff, success: #28a745) {
.text-#{$name} {
color: $color;
}
}
性能和可维护性容易被忽略的细节
每次调用 @each 都会生成一份完整 CSS 规则，不压缩、不去重。如果 map 有 50 个键，就生成 50 个独立类——哪怕其中 48 个根本没在 HTML 中使用。
- 开发阶段建议配合
@if map-has-key($map, $key)做白名单过滤，避免无用输出 - 不要在
@each内部调用@function处理复杂逻辑，Sass 编译器不会优化，可能拖慢构建速度 - 若需响应式变体（如
.md:text-primary），别用两层@each嵌套，改用@for+ 列表组合，否则生成规则数呈指数增长
真正麻烦的不是写错语法，而是后期要删掉某个颜色时，得同时清理 map、循环逻辑、可能还涉及 JS 里对应的字符串引用——@each 把“写一次”变成了“改一处，查五处”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
