应使用语义化、职责分离的原子mixin：.card-padding(@size)和.card-spacing(@size)分别管控内边距与外边距；.card-radius(@size)和.card-shadow(@level)须分开定义，避免视觉与渲染逻辑耦合；参数仅接受sm/md/lg等字符串关键字，禁用像素值及混用单位。
直接用变量管卡片的间距和圆角，不如用语义化 Mixin——变量改了，所有地方都跟着变，但 padding 和 margin 本就该解耦，圆角也不该和阴影混在一起。
为什么不能只靠 @card-padding 这类变量
常见错误是定义一个 @card-padding: 16px，然后在所有卡片里写 padding: @card-padding。问题在于：这个值到底是内边距还是外边距？如果某处误用成 margin，视觉错位后很难定位；更糟的是，换肤或适配窄屏时，你得挨个检查是改 @card-padding 还是加新变量，逻辑迅速失控。
-
@card-padding和@card-margin必须分开声明，哪怕初始值相同 - 变量名不带语义（比如叫
@spacing-md）会导致调用方无法判断用途，后期维护成本翻倍 - 圆角同理：
@card-radius只能用于border-radius，不能塞进overflow: hidden或阴影计算里
.card-padding() 和 .card-spacing() 怎么写才不踩坑
这两个 Mixin 要严格区分职责：前者只处理内容留白（padding），后者只控制卡片之间距离（margin）。参数统一用字符串关键字，避免传入像素值导致单位混乱。
- 接受
@size: sm、md、lg，内部映射到具体数值：sm: 8px、md: 16px、lg: 24px - 不支持数字参数：
.card-padding(12px)会破坏语义收敛，禁止在项目规范中出现 - 调用时必须显式写出用途：
.my-card { .card-padding(md); .card-spacing(sm); }，不能合并成一个.card-layout()
.card-radius() 为什么要和 .card-shadow() 分开定义
圆角影响容器形状与裁剪边界，阴影影响层级感知，二者渲染路径不同。合并在一个 Mixin 里，会导致修改圆角时意外重置阴影值，或者为适配深色模式单独覆盖时牵连出错。
-
.card-radius(@size: md)只输出border-radius，值映射为：sm: 4px、md: 8px、lg: 12px - 禁用
inherit或0以外的特殊值（如50%），防止在小尺寸卡片上溢出 - IE11 不支持
border-radius的百分比值，所以lg不能映射到50%，必须是固定像素
响应式场景下怎么动态切换这些值
别在 Mixin 内部写 @media。响应式切换由调用方控制，Mixin 只负责把语义值转成 CSS——这样编译体积可控，断点逻辑也集中在外层。
- 正确写法：
.product-card { .card-padding(md); .card-radius(md); @media (max-width: 767px) { .card-padding(sm); .card-radius(sm); } } - 错误写法：
.card-padding(@size) { @media (max-width: 767px) { padding: ... } }—— Mixin 失去复用性，且容易触发 Less 编译顺序 bug - 所有断点必须来自统一变量：
@bp-sm: 576px、@bp-md: 768px，禁止硬编码像素值
最易被忽略的是：圆角和阴影的视觉匹配度。比如 .card-radius(lg) 配 .card-shadow(base) 会显得浮空，但 Mixin 本身不校验这种组合——这得靠设计系统文档约束，而不是靠代码强制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
