Less不支持原生批量继承与重载，需用参数化mixin模拟：封装可选参数的样式块（如.btn-style），配合when守卫处理跳过属性；慎用:extend()以防样式污染；通过@import+守卫mixin实现模块化主题重载。
Less 本身不支持 CSS 属性的“批量继承”（像 Sass 的 @extend 那样复用选择器规则），也没有原生的“重载”机制；所谓“批量继承与重载”，实际是通过 .mixin + 参数化 + & 嵌套组合实现的模拟行为——关键在于避免硬编码重复，同时保留覆盖灵活性。
用带参数的 mixin 封装可复用的属性块
这是最直接、最可控的方式。把一组常被共用的声明（如间距、颜色、圆角）抽成 mixin，并允许部分参数有默认值，调用时按需覆盖。
常见错误是写成无参 mixin 或过度嵌套导致调用不直观；正确做法是让每个参数语义清晰、可选且有合理 fallback：
.btn-style(@padding: 8px 16px, @bg: #007bff, @radius: 4px) { padding: @padding; background: @bg; border-radius: @radius; }- 调用：
.btn-primary { .btn-style(10px 20px, #0056b3); }—— 只改前两个参数，@radius仍用默认值 - 若某处需要完全跳过某个属性（比如不设
border-radius），就传none或initial，并在 mixin 内部用when守卫判断是否输出
用 & 嵌套 + :extend() 模拟选择器级继承（慎用）
:extend() 确实能复用选择器样式，但它会合并选择器、生成冗余 CSS，且无法传参或条件控制，容易引发意料外的样式污染。
立即学习“前端免费学习笔记（深入）”；
典型误用场景：用 .base-btn:extend(.reset all) 强行“继承”一堆基础样式，结果 .reset 里任何改动都波及所有扩展处，维护成本陡增。
更稳妥的做法是：
- 只对**真正静态、永不变化**的原子类（如
.sr-only,.clearfix）用:extend() - 避免跨模块 extend，比如不要让组件文件 extend 工具类文件里的选择器
- 永远检查编译后 CSS：如果发现
.a, .b, .c { ... }这种长选择器列表，说明 extend 已失控
用 @import + guarded mixins 实现模块化重载
当多个组件需要共享一套视觉规则（如主题色、断点、字体栈），但又允许局部覆盖时，应把变量和 mixin 分离管理：
- 在
variables.less中定义@primary-color: #007bff;和@spacing-xs: 4px; - 在
mixins.less中写.themeable() when (@theme = 'dark') { ... }，配合@theme变量切换逻辑 - 各组件文件
@import这两个文件，再通过.themeable()调用，而非直接引用变量——这样重载只需改@theme或传不同参数，不影响其他模块
性能影响很小，但路径必须写对：@import "./mixins"; 不能漏掉引号和扩展名，否则 Less 会静默失败，编译出错信息里可能只显示 ReferenceError: .themeable is undefined，容易误判为语法问题。
真正难的是权衡：mixin 太细碎，调用成本高；太粗放，又失去定制能力。多数团队卡在“该不该把 margin/padding 拆成独立 mixin”这种细节上——其实只要保证每次修改只影响一个维度（比如只动 @spacing 变量就能全局调间距），就比强行“继承”更可靠。
