应统一使用@border-radius-base变量控制所有圆角，确保所有样式显式引用该变量且所在文件正确@import变量文件，避免硬编码或未导入导致修改无效。
如何用 Less 变量控制所有边框圆角
直接改 @border-radius-base 就能统一调整按钮、卡片、输入框等所有组件的圆角——前提是你的 Less 项目里真正在用这个变量，而不是只在文档里写了它。
很多团队写了一堆 @border-radius-sm、@border-radius-lg，但实际样式里写的是硬编码的 4px 或 8px，变量根本没被消费。结果改变量毫无反应，还以为 Less 不生效。
- 所有带圆角的 CSS 规则必须显式引用变量，比如
border-radius: @border-radius-base;，不能只靠命名暗示“这里该用变量” - 推荐只定义一个基础变量
@border-radius-base，复杂组件（如带图标输入框）再基于它做计算：border-radius: (@border-radius-base + 1px); - 避免定义过多层级变量（如
@border-radius-card、@border-radius-btn），除非它们真有设计意义上的差异；否则维护成本陡增，且容易漏同步
为什么修改变量后部分圆角没变
常见现象：改了 @border-radius-base，按钮圆角变了，但弹窗、下拉菜单还是尖角——大概率是这些组件的样式来自第三方库（如 Ant Design、Element UI）或独立 Less 文件，压根没 import 你的变量文件。
Less 没有全局变量作用域，@border-radius-base 只在当前文件或明确 @import 进来的上下文中有效。
立即学习“前端免费学习笔记（深入）”；
- 检查目标样式所在 Less 文件顶部，是否
@import了存放变量的variables.less（或类似路径） - 第三方 UI 库的样式通常不读取你的变量，要么覆盖它的类（用更高优先级选择器 +
!important，慎用），要么用 CSS 自定义属性桥接：border-radius: var(--border-radius-base, 6px); - Webpack 的
less-loader配置里如果启用了modifyVars，它只影响首次编译入口，无法动态更新已 import 的子文件变量
兼容性与编译后 CSS 的实际表现
Less 变量本身不产生兼容性问题，但圆角值最终输出为标准 CSS border-radius，需留意旧版 Safari（iOS 8–9）对百分比或复合值（如 2px / 4px）的支持不稳。
如果你的变量设成 @border-radius-base: 50%;，它会在所有支持 border-radius 的浏览器生效；但若设成 @border-radius-base: 0 0 8px 8px;，就要确认设计是否真需要这种非对称圆角——多数 UI 系统只用单值，保持一致性更可控。
- 移动端 H5 项目建议坚持用单像素值（如
4px、6px），避免em或rem单位，防止缩放时圆角比例失真 - 编译后 CSS 里不会出现
@border-radius-base，只有具体数值，所以无需担心运行时性能 - 若需响应式圆角（如小屏用
4px，大屏用8px），Less 无法直接实现，得切到 CSS 自定义属性 + 媒体查询
和 CSS 自定义属性混用时的关键陷阱
有人想“既用 Less 编译时变量，又留 Runtime 调节口”，于是这样写：border-radius: @border-radius-base; border-radius: var(--border-radius-base);——这是错的。后者会完全覆盖前者，因为 CSS 层叠规则中后声明的生效。
真正安全的桥接方式是让 Less 输出 CSS 变量，而非并存两套：
:root {
--border-radius-base: @border-radius-base;
}
然后在需要动态调整的地方用 var(--border-radius-base)，编译时仍由 Less 控制源头。
- 不要在同一个声明块里混用 Less 变量和 CSS 变量赋值给同一属性
- 如果项目已大量使用 CSS 变量，Less 变量就退化为“配置生成器”，只负责把设计值写进
:root，不再直接参与样式计算 - 注意 Webpack 的
less-loader默认不支持var()函数，遇到ParseError是因为它把var(--x)当作 Less 函数了——需关闭math选项或升级 less-loader 版本
@import 变量文件的弹窗组件。 
