Less中用参数化混合器.avatar(@size)统一控制头像宽高、圆角（@size/2）、字体大小（floor(@size/3)）、基线对齐等，扩展状态通过命名空间子混合器（如.avatar-border()）分层叠加，限定常用5档尺寸并配合主题变量实现可维护性。
Less中怎么用参数化混合器定义头像尺寸
直接用 .avatar() 混合器传入尺寸值，就能生成对应宽高、圆角、字体大小的样式，不用为每个尺寸重复写一遍CSS。关键在于把尺寸作为变量参与所有相关属性计算，而不是只改 width 和 height。
常见错误是只缩放容器，忘了同步调整内部文字大小或边框粗细，导致小头像里文字撑出、大头像里图标发虚。
-
@size是核心参数，单位统一用px（避免rem在混合器里换算复杂） - 圆角固定为
@size / 2，保证始终是正圆 - 字体大小按比例设为
floor(@size / 3)，避免小尺寸下文字模糊（如12px头像配4px字会渲染异常） - 默认加
vertical-align: middle，解决行内头像基线对齐问题
为什么不能直接用CSS自定义属性替代Less混合器
纯CSS变量（--avatar-size）无法在 :not()、@media 或选择器嵌套中动态生成新类名，而组件库通常需要预设 .avatar-sm、.avatar-lg 这类静态类。Less混合器能在编译期展开成真实CSS规则，不增加运行时负担。
另一个实际限制：CSS变量无法驱动 @keyframes 或伪元素内容计算，而头像组件常需配合动画（如加载态旋转）或状态徽标（右上角小红点），这些都依赖编译期确定的尺寸值。
立即学习“前端免费学习笔记（深入）”；
- Less混合器输出的是确定的CSS类，可被PurgeCSS安全识别和保留
- CSS变量需JavaScript配合设置，服务端渲染（SSR）场景下首屏可能闪动
- 调试时浏览器开发者工具看到的是最终生成的类名（如
.avatar-md），比追踪层层var(--size)更直观
如何支持边框、阴影、加载态等扩展状态
在基础混合器上叠加带命名空间的子混合器，比如 .avatar-border() 或 .avatar-loading()，它们复用主尺寸参数，但只注入额外样式，避免重复定义宽高。
容易踩的坑是把所有状态逻辑塞进一个混合器，导致调用时参数过长、语义混乱。应该分层：基础尺寸 → 容器装饰（边框/阴影）→ 内容状态（加载/离线/编辑）。
-
.avatar-border(@size, @border-width: 2px, @color: #e0e0e0)中@border-width默认为@size * 0.02（即2%），保持视觉一致性 -
.avatar-loading(@size)生成background-image: radial-gradient(...)，渐变尺寸按@size * 0.6计算，避免小头像中心白点过大 - 所有扩展混合器必须声明
@size参数，禁止内部硬编码尺寸值
编译后CSS体积和维护风险怎么控制
混合器本身不产生CSS，只有被调用时才输出规则。但如果在循环中无节制调用（比如用 .for() 生成 20 个尺寸），会导致CSS膨胀。实际项目建议限定常用尺寸档位：xs / sm / md / lg / xl，共5个。
更隐蔽的问题是主题切换——如果未来要支持暗色模式，别在混合器里写死颜色值，而是用 @text-color-base 这类主题变量，让混合器成为“尺寸骨架”，颜色/间距等交由主题层覆盖。
- 每个尺寸档位单独调用一次混合器，例如
.avatar-md { .avatar(40px); } - 禁止在
:hover伪类里再次调用混合器（应复用已定义的类，再覆盖局部属性） - 混合器内部避免使用
calc()，Less编译期无法优化，会原样输出到CSS中，影响小屏设备解析性能
最易被忽略的是响应式断点耦合——不要让 .avatar() 自动根据媒体查询缩放，那会破坏组件的尺寸契约。头像尺寸应由父容器或业务逻辑显式指定，混合器只负责“画准这个尺寸”。
