直接写 padding: 16px 会导致内边距无法联动响应，而 --padding 变量通过作用域控制、单位规范、继承与覆盖机制，实现深色模式、响应式及动态修改的统一管理。
为什么直接写 padding: 16px 不如用 --padding 变量
硬编码数值会让所有卡片、按钮、表单控件的内边距失去联动能力。改一个尺寸，就得全局搜索替换；深色模式切换、移动端适配、用户偏好缩放时，根本没法批量响应。而 --padding 是个“开关”，样式规则是“电路”——只动变量值，整套布局节奏就跟着变。
关键不是语法多炫，而是变量是否定义在能被继承/覆盖的作用域里。比如只在 :root 定义却不在 .card.dark 中重设，那深色模式下内边距压根不会变。
-
--padding必须带单位（'1rem'合法，1不合法） - 别用
0.5rem这类易被四舍五入干扰的值，推荐0.75rem/1rem/1.25rem - 组件级变量优先于
:root，比如.modal { --padding: 24px; }比全局更可控
怎么写才能让 padding: var(--padding) 真正生效
很多人写了变量却没效果，问题常出在三处：继承失效、box-sizing 冲突、或选择器没命中。
- padding 不继承，所以必须在目标元素上显式写
padding: var(--padding)，不能指望父级设了子级自动有 - 务必搭配
box-sizing: border-box，否则--padding: 16px会让元素总宽 = width + 32px，破坏布局预期 - 如果用了简写（如
padding: var(--padding) 0），IE 和部分旧 Safari 会解析失败；要分方向控制，就拆成--padding-top、--padding-bottom
响应式中改 --padding 的安全写法
不是每个断点都重写一遍 padding，而是只更新变量值，复用同一套规则。但顺序和作用域容易翻车。
立即学习“前端免费学习笔记（深入）”；
- 所有媒体查询里的变量重定义，统一写在
:root下，别分散到不同选择器里 - 避免顺序错乱：先写
@media (max-width: 768px)，再写@media (min-width: 769px)，后者若没加!important可能被前者覆盖（尤其变量在:root定义时） - 慎用
calc(var(--padding) * 1.2)：Safari 15.4 之前对calc嵌套var()支持不稳定，建议直接设新值
JS 动态修改 --padding 的坑点
用 JS 控制内边距比操作 style.padding 更干净，但单位缺失、作用域错位、性能卡顿这三点最常导致失败。
- 必须带单位：
element.style.setProperty('--padding', '12px')合法，'12'会导致计算失效 - 批量修改多个卡片时，优先改父容器（如
document.body.style.setProperty('--padding', '12px')），让子元素通过继承生效，比遍历每个 DOM 节点高效 - 如果 padding 需随滚动变化，用
requestAnimationFrame节流，别在scroll事件里直接setProperty，否则视觉卡顿明显
实际项目中最容易被忽略的，是变量命名和作用域的耦合程度——--padding 这种泛称在复杂组件树里极易冲突，真正稳定的做法是按语义+层级来定名，比如 --card-padding-y 或 --form-field-padding-inline。
