less中可复用阴影mixin应语义化分档（如.shadow-sm/.md/.lg），参数按css顺序设计，颜色用fade()或css变量；圆角mixin需统一变量、避免多向参数；组合使用时border-radius须≥blur+spread以防锯齿；精简档位、删除未引用mixin以控体积。
Less里怎么写可复用的阴影Mixin
直接用.shadow()这种调用最省事，但得先定义带参数的Mixin。关键不是堆效果，而是把常用阴影层级拆成语义化档位：比如@shadow-sm对应卡片浮起，@shadow-md用于模态框，@shadow-lg留给悬浮操作栏。别一股脑塞box-shadow: 0 2px 4px rgba(0,0,0,.1)这种硬编码值——改一处要翻十处。
- 参数顺序按CSS书写习惯来：
@x、@y、@blur、@spread、@color，最后加个@inset布尔开关 - 颜色默认用
fade(#000, 10%)而不是写死rgba(0,0,0,.1)，方便主题色切换时自动适配 - 如果项目用了CSS变量做主题，Mixin里就别硬写
@color，改用var(--shadow-color, #000)兜底
.shadow(@x: 0, @y: 2px, @blur: 4px, @spread: 0, @color: fade(#000, 10%), @inset: false) {
box-shadow: ~"@(inset) @(x) @(y) @(blur) @(spread) @(color)";
}
圆角Mixin怎么避免响应式场景下失效
.rounded()看着简单，一到移动端适配就出问题：按钮在小屏要4px，卡片却要8px，而弹窗角半径又得是12px。硬写三套类名？不如用参数控制基础值+媒体查询钩子。
- 默认参数设为
@radius: 4px，但所有调用都走.rounded(@radius)，不直接写死像素值 - 在根变量文件里统一定义
@radius-sm: 4px、@radius-md: 8px、@radius-lg: 12px，业务层只引用这些语义名 - 真要响应式？别在Mixin里写
@media，而是在调用处包裹：@media (max-width: 768px) { .btn { .rounded(@radius-sm); } }
常见错误是把border-radius拆成四个方向单独参数——实际95%场景四角一致，多参数反而增加误用概率。
组合使用阴影和圆角时的渲染优先级问题
box-shadow和border-radius一起用，圆角切不到阴影上，边缘发虚。这不是Less的问题，是浏览器渲染机制：阴影在绘制时会按元素原始矩形区域扩散，再被border-radius裁剪。
- 必须确保
border-radius值 ≥box-shadow的@blur + @spread之和，否则阴影被硬切，出现锯齿 - 比如用
.shadow(@y: 4px, @blur: 12px, @spread: 2px)，那.rounded()至少得14px - 更稳妥的做法：在Mixin里加校验注释
// ⚠️ @radius should >= @blur + @spread when used together
有些团队用overflow: hidden强行裁剪，但会干掉下拉菜单、Tooltip等溢出内容——治标不治本。
编译后CSS体积和维护成本怎么平衡
每多一个参数组合，Less就生成一条独立CSS规则。比如.shadow()支持5个参数，每个参数3种取值，理论上可能膨胀出3^5 = 243条规则——但实际没人这么用。
- 只暴露业务真正需要的组合：比如
.shadow-sm、.shadow-md、.shadow-lg三个固定档位，背后共用同一个Mixin，不额外导出参数版 - 把
.rounded-sm、.rounded-md这类工具类抽成独立class，而不是全靠Mixin调用——避免组件内部重复计算 - 最容易被忽略的是：删除未使用的Mixin引用。Less不会自动tree-shake，
.shadow()写在utils.less里，但某个模块没import它，照样编译进最终CSS
参数化是为减少重复，不是为炫技。定好三档阴影、三档圆角、两档内凹/外凸，比搞出八种变体更可持续。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
