直接写 padding: 16px 足够的场景无需变量；但涉及深色模式、响应式、用户偏好或批量主题切换时，--padding 是必须的——否则维护成本陡增。失效主因有三：padding 不继承、box-sizing 为 content-box 导致溢出、变量作用域不匹配。真正可管理的关键在于：全局默认值写在 :root，分支逻辑在同级作用域重定义，单位必须显式携带，组件级变量优先于全局，媒体查询统一置于 :root 下且注意顺序，慎用 calc 嵌套，JS 修改需带单位、选对作用域、节流并确保 DOM 已挂载，变量名与引用必须严格一致。
直接写 padding: 16px 就够用的场景，别硬上 --padding 变量；但只要涉及深色模式、响应式缩放、用户偏好或批量主题切换，--padding 就不是“可选”，而是必须——否则改一处，全局搜三遍，还漏掉伪元素和动态插入的节点。
为什么 padding: var(--padding) 写了却没效果
不是语法错，是三个隐性断点同时触发：
-
padding不继承，父级设了--padding: 1rem，子元素没显式写padding: var(--padding)，那就等于没写 -
box-sizing还是默认的content-box，--padding: 16px一加，元素总宽 =width + 32px，布局当场溢出 - 变量定义在
.card里，媒体查询却在:root下重设，作用域不匹配，断点切换后值根本没更新
怎么定义 --padding 才算真正“可管理”
关键不在“有没有变量”，而在变量是否落在能被覆盖的作用域里：
- 全局默认值必须写在
:root：例如:root { --padding: 1rem; }，别只塞在某个组件选择器里 - 深色模式、移动端等分支，必须在同级作用域重定义：比如
.card.dark { --padding: 0.75rem; }，而不是指望:root里的值自动变 - 单位必须显式携带：
--padding: 1rem合法，--padding: 1无效；0.5rem易被四舍五入干扰，优先用0.75rem/1rem/1.25rem - 组件级变量优先于
:root：.modal { --padding: 24px; }比全局更可控，也避免污染其他组件
响应式中改 --padding 的安全写法
不是每个断点都重写一遍 padding，而是只更新变量值，复用同一套规则。但顺序和作用域极易翻车：
立即学习“前端免费学习笔记（深入）”；
- 所有媒体查询里的变量重定义，统一写在
:root下，别分散到不同选择器里 - 避免顺序错乱：先写
@media (max-width: 768px)，再写@media (min-width: 769px)，后者若没加!important可能被前者覆盖（尤其变量在:root定义时） - 慎用
calc(var(--padding) * 1.2)：Safari 15.4 之前对calc嵌套var()支持不稳定，建议直接设新值，比如--padding: 1.25rem - 移动端常用
--padding: 0.75rem，PC 端用--padding: 1.25rem，差值别超过0.5rem，否则视觉跳跃明显
JS 动态修改 --padding 最常踩的坑
用 JS 控制比操作 style.padding 更干净，但单位缺失、作用域错位、性能卡顿这三点最常导致失败：
- 必须带单位：
element.style.setProperty('--padding', '12px')合法，'12'会导致计算失效 - 批量修改多个卡片时，优先改父容器（如
document.body.style.setProperty('--padding', '12px')），让子元素通过继承生效，比遍历每个 DOM 节点高效 - 如果
padding需随滚动变化，用requestAnimationFrame节流，别在scroll事件里直接setProperty，否则卡顿明显 - 确保元素已插入 DOM 再调用
setProperty，否则无效；挂载时机不对，变量设了也白设
最容易被忽略的一点：变量名和 padding 声明必须成对出现。比如定义了 --card-padding，但所有 .card 里写的却是 padding: var(--pad)，那整个机制就断在第一步。
