直接用 border-radius 硬编码会导致维护失控，应改用语义化 CSS 自定义属性（如 --radius-sm、--radius-md）统一管理；避免单变量 --radius 和缩写语法混用，非对称圆角须拆分为独立属性；百分比值需结合实际尺寸验证，动画场景慎用动态修改。
为什么直接用 border-radius 做全局圆角会失控
当你在多个组件里反复写 border-radius: 8px、border-radius: 12px、border-radius: 50%，很快就会发现：改一个数值要搜遍整个项目，UI规范更新时漏改某处是常态。更麻烦的是，不同语境下“小圆角”含义可能不一致——按钮要 4px，卡片要 8px，头像要 50%，硬编码会让维护成本指数级上升。
用 CSS 自定义属性（--radius）替代硬编码值
把圆角半径抽成自定义属性，就能在一处定义、多处复用，且支持计算和条件覆盖。关键不是“能不能用”，而是怎么组织才不易出错：
- 根元素定义基础集：
:root { --radius-xs: 2px; --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --radius-full: 50%; } - 组件内直接引用：
border-radius: var(--radius-md); - 需要局部覆盖时，就近重定义：
.card--compact { --radius-md: 6px; border-radius: var(--radius-md); } - 避免用
var(--radius)单一变量——它没有语义，后续无法区分是“按钮圆角”还是“弹窗圆角”，容易误覆盖
border-radius 缩写语法和自定义属性混用的坑
自定义属性不能直接塞进 border-radius 的多值缩写中，比如这样会失效：border-radius: var(--radius-sm) var(--radius-md);。浏览器解析时会把整个值当做一个 token，而 CSS 不支持在缩写属性中部分使用 var()。
- 正确做法是拆成独立属性：
.btn { border-top-left-radius: var(--radius-sm); border-top-right-radius: var(--radius-sm); border-bottom-right-radius: var(--radius-md); border-bottom-left-radius: var(--radius-md); } - 或退一步，用单值统一控制（多数 UI 场景够用）：
border-radius: var(--radius-md); - 如果真要非对称圆角，优先用独立属性，别贪图缩写——可读性和可维护性远比少打几个字符重要
响应式圆角与百分比值如何配合自定义属性
用百分比实现圆形头像或椭圆容器时，var(--radius-full) 看似合理，但要注意：50% 是相对于宽/高分别计算的，而自定义属性本身不带上下文。所以 --radius-full: 50%; 没问题，但 --radius-ellipse: 100px / 150px; 这种斜杠语法不能直接放进 var()，因为 CSS 不支持在 var() 中解析斜杠分隔结构。
立即学习“前端免费学习笔记（深入）”；
- 椭圆类需求建议放弃自定义属性，直接写死：
border-radius: 100px / 150px; - 或者封装为 class：
.avatar--circle { border-radius: var(--radius-full); } .badge--ellipse { border-radius: 20px / 10px; } - 真正要警惕的是
--radius: 25%;这类定义——25% 在正方形上是圆角，在窄长容器上可能变成一条缝，务必在实际尺寸下验证效果
最常被忽略的一点：自定义属性本身不触发重绘，但它的值一旦被用于 border-radius，就参与 layout 和 paint 阶段。在频繁动画的元素上滥用 var(--radius) 并动态修改，可能引发不必要的渲染开销，尤其在低端 Android 设备上。圆角管理的目标是清晰可控，不是无脑替换。
