@each 比 @for 更适合栅格系统，因栅格本质是断点名→值的映射关系，@each 天然适配 map 结构，避免索引维护与字符串拼接错误，而 @for 易将语义化断点写成数字序号导致后期难以维护。
直接用 @each 配合 map 就能生成响应式栅格类，但写错 key-value 结构或漏掉单位转换，生成的 class 会全失效。
为什么 @each 比 @for 更适合栅格系统
栅格系统本质是「断点名 → 列数/偏移量/顺序值」的映射关系，不是纯数字序列。@each 天然适配 map 数据结构，避免手动维护索引和字符串拼接；而 @for 容易把 sm、md 这类语义化断点写成 1、2，后期改断点名就得全量重算。
常见错误现象：@for $i from 1 through length($breakpoints) 后用 nth($breakpoints, $i) 取键，结果取到的是整个键值对或空值——Sass 的 map-keys() 才该配合 @each 用。
实操建议：
- 定义断点用
$grid-breakpoints: (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px); - 列数配置用独立 map：
$grid-columns: (xs: 12, sm: 12, md: 12, lg: 12, xl: 12); - 别把断点和列数塞进同一个 map——后续要分别遍历，混在一起会让逻辑缠绕
生成 .col-{bp}-{n} 类时必须处理单位转换
Sass map 里存的 sm: 576px 是带单位的长度值，但类名里不能出现 px；同时，列宽计算要用 percentage($n / $total-columns)，不是直接写死 8.333%。
容易踩的坑：@each $breakpoint, $width in $grid-breakpoints 中的 $width 是 576px，如果误当成数值参与除法（比如 $width / 12），编译直接报错 "Incompatible units px and unitless"。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
实操建议：
- 用
map-get($grid-columns, $breakpoint)单独取当前断点的总列数 - 类名拼接用
if($breakpoint == xs, "col-#{$n}", "col-#{$breakpoint}-#{$n}")，避免col-xs-6和col-sm-6写法不一致 - 宽度计算统一走
percentage($n / $cols)，$cols来自map-get($grid-columns, $breakpoint)
响应式偏移（offset）和顺序（order）类要单独遍历
偏移和顺序的数值范围跟列数无关（比如 offset-1 到 offset-11，order-1 到 order-12），硬套列数 map 会导致生成多余类（如 offset-xl-12 在 12 列系统里无意义）。
性能影响：每个断点都生成全部 offset/order 类，CSS 体积增长快；但比起手写，仍是可接受的权衡。
实操建议：
- 偏移用固定范围：
$offsets: 0 1 2 3 4 5 6 7 8 9 10 11;，再@each $breakpoint, $width in $grid-breakpoints套一层 - 顺序类加
!important要谨慎：order-#{$breakpoint}-#{$n} { order: #{$n} !important; }，否则可能被其他样式覆盖 - 跳过
xs断点的 offset 类（因无媒体查询，offset-xs-3实际等价于margin-left: 25%，易冲突）
最易被忽略的是断点顺序——Sass @each 遍历 map 时顺序不保证，xs、sm、md 必须按移动端优先排序，否则媒体查询嵌套会错乱。用 map-keys($grid-breakpoints) 显式取键数组并按需排序，比依赖原 map 插入顺序更可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
