用Sass的@each遍历图标map（如$icons: ("home": "\e900", "user": "\e901")），生成.icon-#{$name}类并设content: "#{$code}"，需用双引号包裹Unicode转义，配合@font-face声明字体，推荐map而非list以确保名码映射准确。
如何用Sass循环生成图标类名
直接生成 .icon-home、.icon-user 这类类名，不用手写几十个——核心是把图标名列表交给 @each，再拼出类选择器和对应的 content 值。
常见错误是把图标名当字符串硬编码进 content，结果输出的是文字而非 Unicode 字符；或者忘了加引号导致 Sass 报 Undefined variable。
- 图标名必须存在一个 map 或 list 里，比如
$icons: ("home": "e900", "user": "e901") - 用
@each $name, $code in $icons遍历，类名用.icon-#{$name}拼接 -
content值必须用双引号包裹，且确保是合法的 Unicode 转义（如"e900"），单引号会失效 - 如果用字体图标（如 Icomoon），记得提前在 CSS 中声明
@font-face并设置font-family
Sass map vs list：选哪个存图标数据
map 更适合带语义的图标管理，list 适合纯顺序枚举。但实际项目里几乎都用 map——因为要同时存名字和对应码点，list 很难保持索引对齐。
用 list 容易踩的坑：$icons: "home" "user" 看似简洁，但没法关联码点；想用 nth($icons, $i) 取值还得额外维护一个平行数组，极易错位。
立即学习“前端免费学习笔记（深入）”；
- 推荐用 map：
$icons: ("home": "e900", "search": "e902", "close": "e905") - map 支持嵌套，后续扩展（比如分组、添加 SVG fallback）更自然
- 如果图标来自 JSON 导出（如 Icomoon 的
selection.json），可用工具转成 Sass map，别手敲
@extend 和 @mixin 哪个更适合图标复用
都不推荐直接用于图标类生成本身，但 @mixin 更安全。用 @extend 会导致 CSS 输出体积膨胀，尤其当多个图标类都 @extend 同一个基础样式时，Sass 会复制所有选择器。
典型问题：写了 @extend %icon-base，结果生成的 CSS 里每个 .icon-xxx 都重复一遍 display: inline-block; font-family: 'Icons'; ——完全违背“复用”初衷。
- 用
@mixin icon-base()封装公共样式，每个类里@include icon-base - 如果真要用
@extend，只限于极少数基类（如重置vertical-align），且确认不会触发选择器爆炸 - 更轻量的做法：把公共属性写成独立类，比如
.icon，再让.icon-home多类共用——HTML 里写class="icon icon-home"
生成类名时如何避免 CSS 冲突或覆盖
关键不是“怎么生成”，而是“生成到哪”。很多人把图标类直接塞进全局作用域，结果和第三方 UI 库的 .icon-* 碰撞，或者被更高权重的选择器覆盖。
最常被忽略的一点：没加命名空间前缀，比如直接生成 .user，而项目里已有 .user { color: red } 的用户模块样式。
- 强制加统一前缀，如
.ic-home、.ic-user，比.icon-*更不易冲突 - 用
@at-root控制输出位置，避免嵌套层级污染（比如不要在.header { ... }里生成图标类） - 如果项目用 CSS Modules 或 scoped style，Sass 生成的类名会被自动 hash，此时需改用
:global(.icon-home)显式导出 - 上线前用
grep -r "icon-" dist/扫描构建产物，确认没意外注入或重复
真正麻烦的不是循环语法，而是图标码点更新后忘记同步 Sass map——人肉比对 JSON 和 .scss 文件，十次有八次漏掉一个。自动化这步才是卡点。
