应封装语义化、参数精简的@mixin card-base($radius: 8px, $shadow: $shadow-md, $has-hover: true)，通过变量管理阴影、分离职责、限定适用场景，并注意高DPI兼容性。
怎么用 Sass @mixin 一次性写好卡片的阴影和圆角
直接封装成可复用的 @mixin，比每次手写 border-radius 和 box-shadow 快得多，也更可控。关键是把变化点抽出来当参数，而不是写死值。
常见错误是把所有样式都塞进一个 @mixin，结果调用时传一堆数字，根本记不住哪个参数对应什么——比如 @include card-style(4px, 0 2px 8px rgba(0,0,0,0.1), 1)，过三天自己都看不懂。
- 只暴露真正需要变的参数：圆角大小、阴影强度、是否启用过渡（hover 效果）
- 阴影用语义化变量名，比如
$shadow-sm、$shadow-md，而不是直接传box-shadow值 - 默认值要合理：
$radius: 8px比4px更符合现代 UI 直观感受
@mixin card-base($radius: 8px, $shadow: $shadow-md, $has-hover: true) {
border-radius: $radius;
box-shadow: $shadow;
@if $has-hover {
transition: box-shadow 0.2s ease, transform 0.2s ease;
&:hover {
box-shadow: $shadow-md;
transform: translateY(-2px);
}
}
}
为什么不能直接在 @mixin 里写死 box-shadow 值
硬编码阴影会导致维护成本飙升：设计改了主阴影色、或要适配深色模式时，得全局搜 box-shadow: 0 2px 12px rgba(0,0,0,0.15)，一漏就错。更糟的是，不同卡片层级（如弹窗 vs 列表项）本该用不同阴影，但写死就只能复制粘贴改数值。
- 把阴影定义收口到变量里（如
$shadow-sm: 0 1px 3px rgba(0,0,0,0.08)），@mixin只负责“用”，不负责“定” - 变量放
_variables.scss，@mixin放_mixins.scss，职责清晰 - 深色模式下只需重定义变量，不用动任何
@mixin调用
哪些地方不该用这个 @mixin
不是所有带圆角和阴影的元素都适合套这个 @mixin。它专为「内容容器类卡片」设计，比如用户卡片、文章摘要、设置项区块。一旦偏离这个场景，强行套用反而增加理解负担。
立即学习“前端免费学习笔记（深入）”；
- 按钮：用
@button-style更合适，按钮需要 focus/hover/active 状态，且圆角常和尺寸强关联 - 输入框：
border-radius往往和边框、内边距耦合紧密，单独抽阴影圆角意义不大 - 图标背景：可能只需要单边圆角（如左上+右上），而
@mixin默认四角统一，硬调参数反而别扭
Sass 编译后 CSS 体积和性能影响
用 @mixin 不会膨胀 CSS 体积——Sass 是编译时展开的，最终生成的还是普通 CSS 规则。但要注意两点：一是别在循环里无脑调用（比如 @for $i from 1 through 10 { .card-#{$i} { @include card-base; } }），这会产生冗余规则；二是避免嵌套过深再套 @mixin，调试时定位困难。
- 推荐写法：
.card { @include card-base; }，干净、可查、易覆盖 - 慎用嵌套调用：
.card { .header { @include card-base; } }—— 这会让.card .header继承卡片样式，逻辑错位 - 如果项目用 CSS-in-JS 或 Tailwind，这类
@mixin就不该存在，属于技术栈错配
最常被忽略的一点：圆角和阴影的组合在高 DPI 屏幕或缩放比例非 100% 时，边缘可能发虚。这不是 @mixin 的问题，但封装时最好加个注释提醒——比如 // 注意：部分安卓 WebView 下 border-radius + box-shadow 叠加易糊，必要时加 transform: translateZ(0)。
