Less中用参数化混合实现多方向box-shadow的正确方式是用预设方向关键词（如top、bottom-right）映射水平/垂直偏移量，而非角度计算；支持八方向语义化调用，分层投影推荐拆分为.shadow-base()和.shadow-ambient()组合使用，避免字符串拼接；高频样式应提取为class以减少冗余CSS。
Less中用参数化混合实现多方向box-shadow
直接写死 box-shadow 值无法复用，而Less混合（mixin）配合参数能生成任意方向的投影——关键不是“支持任意方向”，而是把方向映射为水平/垂直偏移量，再结合模糊和扩散控制视觉效果。
常见错误是试图用角度值（如 45deg）直接参与计算，但CSS box-shadow 不接受角度，只接受像素/长度值。必须手动将角度转为 cos(θ) × distance 和 sin(θ) × distance 的近似值，或更实用：用预设方向关键词（top、bottom-right 等）做映射。
-
.shadow(@direction: bottom, @distance: 4px, @blur: 8px, @spread: 0, @color: rgba(0,0,0,0.15))是合理起点 - 方向参数不直接用于数学运算，而是用 guard 条件分支匹配不同偏移组合
- 例如
when (@direction = top)→0 (-@distance) @blur @spread @color - 支持
top/right/bottom/left/top-left/top-right/bottom-right/bottom-left八个方向足够覆盖绝大多数需求
为什么不用三角函数计算真实角度
Less 本身不支持 cos() 或 sin() 运算（除非引入插件或自定义函数），原生计算角度会强制你写一堆近似值表或用 JavaScript 预处理——这违背了“纯Less”的使用场景。实际项目中，设计师给的“右下角投影”从来不是“135度”，而是“往右4px、往下4px”这种明确位移。
真正需要动态角度的场景（比如动画中旋转投影方向），应该交给 CSS 自定义属性 + JS 控制，而不是在编译期用 Less 算。
立即学习“前端免费学习笔记（深入）”；
- Less 编译发生在构建时，无法响应运行时变化
- 用
@distance * 0.707近似 45° 的 x/y 分量，看似聪明，但维护成本高、可读性差 - 八方向映射语义清晰，开发者一眼看懂
.shadow(bottom-right, 6px)效果
混合中如何处理多层投影叠加
单层 box-shadow 往往不够立体，真实 UI 中常需两层：一层短距离高对比（模拟接触阴影），一层长距离低透明（模拟环境光）。Less 混合必须支持多值参数或嵌套调用。
推荐用列表参数或拆分为两个独立混合，避免在单个 mixin 内强行拼接字符串——Less 对字符串拼接的支持脆弱，容易因空格或逗号位置出错。
- 错误写法：
box-shadow: ~"@{x1} @{y1} @{b1}, @{x2} @{y2} @{b2}";（易漏空格、难调试） - 推荐写法：定义
.shadow-base()和.shadow-ambient()，再用.shadow()组合调用 - 示例：
.shadow(@direction, @distance) { .shadow-base(@direction, @distance); .shadow-ambient(@direction, (@distance * 2)); } - 这样每层可单独控制颜色、模糊度，也方便后期覆盖某一层
兼容性与输出体积要注意什么
Less 混合在编译后生成的是静态 CSS，不会增加运行时开销，但滥用会导致冗余代码——比如每个按钮都调用 .shadow(top-right, 2px)，最终 CSS 里重复出现同一段 box-shadow: 2px -2px 4px rgba(...) 多次。
如果项目中大量使用相同投影配置，建议提取为变量或 class，而非无脑复用 mixin。
- 高频共用组合（如卡片浮起效果）应封装成 class：
.card-shadow { .shadow(bottom, 4px); } - 避免在循环（
.for）中调用带复杂逻辑的 shadow mixin，编译速度会明显下降 - 注意
box-shadow在旧版 Safari（inset + 多层叠加有渲染 bug，若需支持，应在 mixin 中加注释提醒
最易被忽略的是 spread 值的符号含义：正值向外扩张，负值向内收缩，但很多设计师给的标注里没写清“扩散”还是“压缩”，实际写的时候得对着 Chrome DevTools 实时调。
