var() 的解析、陷阱与妙用

关键心智模型：自定义属性是一个代换值 (substitution value)，不是普通属性那样「写进去就解析成具体的值」。浏览器只检查它是不是合法的 token 流（几乎什么都收），把这串 token 原样存着；直到某个 var() 在 computed value time 把这串 token 贴回到目标属性里，才真正去解析。

1 · var() 的求值过程

1.1 · fallback 的触发条件

var(--size, 80px) 的第二个参数是 fallback。但它的触发条件很窄：仅当 --size 没被定义，或被显式设成 initial（自定义属性的 guaranteed-invalid value）时才用 fallback。只要 --size 不是 guaranteed-invalid，fallback 就不会出场（哪怕它的值为空）——哪怕那内容代换后是非法的（那是 IACVT 一节（§3）的事）。点下面四个值，看同一句 width: var(--size, 80px) 取到多少：

1.2 · :root 里被冻住的是代换而非算术

自定义属性会继承，而且它继承下来的是已经代换完的 computed 值。所以在 :root 写 --double: calc(var(--base) * 2) 时，var(--base) 在 :root 当场被代换成 10px，往下传的是 calc(10px * 2) 这串 token——被冻住的是代换，不是算术。未注册的自定义属性在 computed value time 只做 var() 代换、不求值 calc()：实测 getComputedStyle(:root).getPropertyValue("--double") 读回的正是 "calc(10px * 2)"。子元素后来把 --base 改大，也带不动那个早已代换定的 --double。若想让它随子元素变化，就不要在 :root 提前计算，把 calc 留到使用它的那一层。

1.3 · 循环引用的暴露时机

自定义属性可以互相引用，--a: var(--b) 在流程图第 1 格「收集声明」里完全合法——它不过是一串合法 token，浏览器并不在这一步追查 --b 是谁。可一旦引用链兜回自己（--a → --b → --a）形成 dependency cycle，问题要拖到第 4 格 computed value time 才暴露：浏览器展开 var() 时检测到环，按规范把环里涉及的每一个自定义属性一起判为 invalid，统统打回 guaranteed-invalid value。后果正好复用前两节的规则——取它的 var() 若带 fallback 就走 fallback（等同未定义）；若没有 fallback、或代换进普通属性后非法，则该属性 IACVT（§3）。点下面切换「成环 / 断开」，看同一句 width: var(--a, 80px) 取到多少：

2 · !important 作用在声明而非值上

自定义属性几乎什么字符都收——--whats-up: (👍ᴗ_ᴗ)👍 都是合法的值。正因为太宽松，很容易以为 --color: red !important 里的 !important 也被当成值的一部分存了进去。并不是。!important 是声明的旗标，在解析时就被剥离，真正存进变量的值只有 red。

旗标和值分家，带来两个反直觉的结论，正是本节要实测的：

• 在自定义属性自身的 cascade 里，带 !important 的声明压过更高 specificity 的声明——这一步就是 var() 一节（§1）流程图的第 2 格（cascade 决胜）。
• 但这个 important 不会顺着 var() 传递给「用到它」的那条声明——一个常被忽略、规范却写得很清楚的细节。

2.1 · 旗标的剥离

给真实元素注入 --color: red !important，再用 getComputedStyle(el).getPropertyValue('--color') 读回来——看它到底存了什么：

2.2 · cascade 中 !important 与 specificity 的次序

这是 Frontend Masters 那篇的核心例子。低 specificity 的元素选择器 p { --color: red !important }；紧挨着用变量的 .greeting（specificity 更高）设 --color: blue。谁赢？切换 !important 看 color: var(--color) 的真实结果：

2.3 · 重要性不随 var() 传递

「cascade」一节里 --color 靠 !important 赢下了「变量的 cascade」，稳定解析成 red。但用它的 color: var(--color) 这条声明本身重不重要，跟变量的 important 毫无关系——它只看自己写没写 !important。所以下面再来一条更高 specificity 的普通 color: green，就能把它压下去：

3 · IACVT 与代换后才暴露的非法

IACVT = Invalid At Computed Value Time（在「计算值」这一步才变非法）。它与常见的「写错了被忽略」是两种失败模式，差别全在什么时候失败：

• 解析期报错——color: 20px 一进门就因类型不符被丢弃，这条声明当没写过，自然回退到上一条合法声明。
• IACVT——color: var(--bad) 语法完全合法，顺利赢下 cascade（把同属性的其他声明都挤掉了）；直到 computed 阶段把 --bad 代换成 20px，才发现对 color 非法。此时已经回不去上一条了——整条声明变成 unset。

3.1 · 两种写法的不同结局

父元素 color: teal；子元素都先写 color: blue，再用两种方式叠一个「非法的颜色」。切换看子元素 getComputedStyle().color 的真实结果：

3.2 · unset 的落点取决于可继承性

IACVT 把声明变成 unset，而 unset 是「见机行事」：可继承属性（如 color）→ 同 inherit，取父值；不可继承属性（如 background-color）→ 同 initial，回属性初始值(transparent)。左右两块用同一个非法变量 --bad: 20px，看落点不同：

3.3 · shorthand 的连带作废

IACVT 作废的是整条声明。若这条声明是 font / margin / background 这类 shorthand，它展开的所有 longhand 会一起 unset——哪怕只有一个子值来自非法的 var()，那些写死的、本来没问题的子值也跟着陪葬。（对比 §3 开头的两条失败模式：字面写错的 shorthand 在解析期就整条被丢，那是另一回事；本节的 shorthand 含 var()，语法合法、赢下 cascade，失败发生在代换之后。）下面两块都想要 italic 700 22px，区别只在 font-family 是写进 font shorthand、还是拆成独立 longhand。把 --family 切成非法值，看谁全垮、谁只丢字体：

3.4 · 现代 CSS 里的隐蔽形态

这个问题在「用 var() 给新特性做回退」时最隐蔽。下面想用 5cqi（容器查询单位）做流体字号、给老浏览器留 var(... , 1rem + 1.5vw) 当 fallback。问题是：在支持 var() 但不支持 cqi 的浏览器里，第二条声明语法合法、赢下 cascade，代换后 5cqi 非法 → 整个 clamp() IACVT → font-size 走 unset。font-size 是可继承属性，unset 即 inherit，于是它落到父元素的字号而非 medium：实测父级 40px 时标题也得 40px，标题层级直接塌掉，fallback 根本没机会上场。

4 · @property 与类型化变量

前面 var()（§1）与 IACVT（§3）两节里的变量都是「未注册的」(unregistered)：无类型、无 initial-value 描述符（初始值是 guaranteed-invalid）、强制继承，且只能离散插值。@property 给变量补上三件元信息——syntax（类型）、inherits（是否继承）、initial-value（初始值），它就「升级」成 registered custom property，行为更可控：

4.1 · 类型检查与非法赋值的落点

最大的不同：registered 变量有类型校验。给它一个不符合 syntax 的值，这次赋值整个无效，同样是 IACVT 走 unset：inherits: false 时落回 initial-value，inherits: true 时先取父值。本页三处演示都用 inherits: false，故都落回 initial-value；换成 inherits: true 时，父级 teal、子级写入非法的 20px，实测子级算出的仍是 teal 而非 initial-value 的 gold。而 unregistered 变量来者不拒，非法值照存，等到 var() 被使用时才以 IACVT 暴露问题（回 unset）。两块都做 background: var(--tint)，给同样的值，看结果：

4.2 · 注册之后的 fallback

还有一个容易忽略的连锁反应。fallback（§1）只在变量是 guaranteed-invalid（未定义或显式赋 initial）时才上场；可一旦用 @property 注册并给了 initial-value，这个变量就再也回不到 guaranteed-invalid——没赋值时它是 initial-value，赋 initial 也只是退回 initial-value。于是 var(--c, fallback) 里的 fallback 形同虚设，真正起回退作用的是 initial-value。两块都写 background: var(--c, hotpink)，左边的 --c 注册过(<color>,initial-value: gold)、右边没注册，切换 --c 的取值看差别：

4.3 · 注册变量的动画能力

未注册变量不可插值——对它做 transition，它只会在中途跳变一次。一旦用 @property 声明了类型（如 <angle> / <color> / <number>），浏览器就知道怎么在两值间平滑插值。下面两块都 transition: --angle .8s 并旋转一个 conic-gradient，点按钮看区别：

5 · token 流代换与字符串拼接的区别

最常被误用的一点：把 var() 想成「字符串替换」。它在 computed value time（§1）做的是 token 流代换——把变量存着的那串 token 原样贴进属性值，不会重新分词，也不会和相邻字符黏成新 token。所以 var(--n)px 不会拼出 120px:120 和 px 始终是两个独立 token。先看这个最高频的「数字接单位」陷阱：

5.1 · var() 的站位限制

同样因为「token 流代换、不参与拼接」，var() 还有一组容易踩的边界——它无法用来拼属性名、嵌进选择器或 media query，也不会钻进 url() 内部去展开。下面几条都不成立，右侧给出对应正解：

6 · 用一个变量开关多处值

Lea Verou 的经典技巧，把 var() 一节（§1）的 guaranteed-invalid 与 fallback 两个特性组合成一个「CSS 布尔开关」。在原生条件语法普及之前，这是用纯 CSS 做条件样式最接近的写法。它只用到两个特殊值：

• --ON: initial——把变量打成 guaranteed-invalid value。被 var(--x, 用这个) 引用时，浏览器当它没定义，于是吃 fallback → 那处样式打开。
• --OFF: ;——值为空。规范明确 --foo:; 是合法的空值而非 guaranteed-invalid，在任何能放 var() 的地方都合法、且不贡献任何内容。被 var(--x, fallback) 引用时变量「有值」，于是跳过 fallback、代换成空，那处样式关闭。

于是一个变量 --raised 设成 var(--ON) 还是 var(--OFF)，就能同时拨动好几条 var(--raised, …) 声明。点开关，看一个变量带动 box-shadow + transform + outline 三处一起亮灭：

6.1 · 追加式用法

上面的开关让整条声明在「fallback 内容」与「空」之间切。Lea 原文的形态是追加：把 var(--toggle, 额外层) 拼在一段固定值前面，开 = 多一层、关 = 只剩固定值。比如给背景可选地叠一层高光渐变：