题干与适用场景
设计系统需要让同一个 padding、颜色或 flex-direction 根据媒体、样式或特性条件变化，同时避免为每个变体复制整组规则。团队提出使用 CSS if()，但仍要支持不识别该函数的浏览器。请给出采用边界、写法和验证计划。
这道题考察 CSS 值求值和级联，不是把 JavaScript 条件搬进样式表。MDN 说明 if() 会按顺序返回第一个为真的分支；CSS Values 5 草案明确未命中时产生空 token stream，声明不会像 @media 那样自动回滚级联。2026 前端面试资料仍把 CSS 布局、级联和浏览器差异作为基础信号，因此答案要能把新语法放回兼容性和调试框架。
面试官考察点
强回答会区分三类条件：media() 描述环境、style() 读取祖先样式查询、supports() 检查浏览器能力。它会先写一个明确的传统声明，再用第二个声明渐进增强；不会假设解析器会忽略未知值后保留同一声明的旧值。
面试官还会检查候选人是否知道分支按书写顺序匹配、else 是总为真的兜底、没有匹配时可能得到 guaranteed-invalid，以及多条声明如何参与级联。回答应包含浏览器矩阵、DevTools 检查和禁用新特性后的视觉回退。
回答前需要澄清的问题
条件来自哪里
确认条件是视口方向、容器的自定义属性，还是浏览器是否支持某个值。视口或用户偏好用 media()；组件状态可用 style()；能力检测用 supports()。如果条件跨多个声明，普通 @media、@container 或 @supports 可能更清楚。
回退必须保持什么
确认旧浏览器只需可读，还是必须保持精确间距、对比度和交互。若是可访问性或布局安全，先提供稳定声明，再用 if() 覆盖；不能让未命中的分支把属性变成初始值。
组件是否允许级联覆盖
确认自定义属性由哪个祖先设置、是否可能被主题层覆盖。style() 查询读取计算后的样式关系；若变量来自同一属性，可能触发循环替换。需要明确 owner 和命名空间，避免组件内部条件读取自己正在计算的变量。
30 秒回答框架
“我先确定条件来源，再决定用 media()、style() 还是 supports()。if() 按分支顺序返回第一个真值，else 提供稳定兜底；没有匹配时结果可能是 guaranteed-invalid，所以我会保留一条传统声明作为旧浏览器回退。跨多个规则的条件仍用 @media、@container 或 @supports。最后用真实浏览器矩阵检查解析、级联、对比度和布局，不把实验性语法当成无条件生产依赖。”
分步骤深入解答
第一步：把条件与职责对应起来
media() 适合方向、宽度和用户偏好；style() 适合组件祖先暴露的状态；supports() 适合值或选择器的能力检测。条件只改变一个属性值时，if() 能减少重复声明；需要同时改变多个属性、伪元素或子树时，规则级查询更容易审查。
第二步：写出明确的求值顺序
CSS Values 5 把参数定义为按顺序排列的条件和值。浏览器评估第一条条件，再继续下一条，直到找到真值；else 永远为真，因此应放在最后。示例：
.card {
padding: 1rem;
padding: if(
style(--density: compact): 0.5rem;
media(width > 60rem): 1.25rem;
else: 1rem;
);
}这里第一条匹配会停止后续判断。写多个相互重叠的条件时，先写更具体的分支，再写通用分支；否则后面的条件永远不会生效。
第三步：理解未命中和旧浏览器回退
未命中且没有 else 时，if() 产生 guaranteed-invalid 或空 token stream。该结果可能让整条声明无效或落到属性的初始行为，不能当作“保留上一条声明”的保证。对关键布局，先写静态声明，再写 if() 声明；不识别 if() 的浏览器会跳过第二条，保留第一条。
.toolbar {
flex-direction: row;
flex-direction: if(media(orientation: portrait): column; else: row);
}如果新浏览器识别 if() 但条件不匹配，else 仍会给出值。若需要整体规则的回退，@supports (padding: if(...)) 比在每个属性里重复复杂条件更容易管理。
第四步：处理 style 查询的级联与循环
style() 查询通常读取祖先或容器暴露的自定义属性。主题层可以设置 --density: compact，组件根据该状态选择值。不要让 --size 的定义同时依赖自身的 if(style(--size: ...))；CSSWG 说明这会被视为循环替换，查询按 false 处理。把状态变量和派生属性分开命名，并在组件文档中写出来源。
第五步：比较 if() 与规则级查询
当只有 color 的一段值随支持情况变化，if(supports(...)) 很合适；当需要切换多个声明，@supports 能把整组规则包起来。当布局依赖容器宽度时，@container 或 media() 的规则块通常比一长串内联值更可读。减少复制不是唯一目标，审查和调试成本也要纳入选择。
第六步：建立浏览器与视觉回归验证
为支持与不支持 if() 的浏览器分别运行页面；检查 CSSOM 中最终值、级联来源、对比度、焦点顺序和布局溢出。覆盖条件未命中、多个条件同时为真、变量未定义、属性值本身无效和 if() 解析失败。若新语法只改善装饰而非核心功能，可把它限制在增强层；若改变可访问性，必须保留可接受的静态基线。
高质量示范回答
我会先问条件来源和回退目标。视口或偏好用 media，组件状态用 style，能力检测用 supports；只有一个属性值需要条件化时才用 if()，多条规则仍用 @media、@container 或 @supports。
求值按书写顺序，第一条为真的分支获选，else 永远为真。没有匹配且没有 else 时不能假设保留旧值，可能得到 guaranteed-invalid。因此关键属性先写静态声明，再写 if() 覆盖。旧浏览器跳过未知声明，现代浏览器用明确的 else。
我会把主题变量和派生属性分开，避免 style 查询形成循环，并把更具体条件放在前面。验证覆盖浏览器支持、CSSOM 最终值、级联、对比度、溢出和未命中分支；如果功能组更清晰，就退回 @supports，而不为减少几行 CSS 牺牲可维护性。
常见错误
- 错误表现 → 没写静态回退 → 失败原因 → 不支持 if() 的浏览器会跳过整条声明 → 修正方法 → 先写稳定值，再写 if() 覆盖。
- 错误表现 → 把 if() 当作规则级 @media → 失败原因 → 它只返回一个属性值，不能替代多声明的布局分支 → 修正方法 → 多属性切换使用规则级查询。
- 错误表现 → 不写 else → 失败原因 → 未命中可能产生 guaranteed-invalid → 修正方法 → 提供明确默认值或保留前一条声明。
- 错误表现 → 让 style() 查询读取自己正在计算的变量 → 失败原因 → 循环替换会使查询失效 → 修正方法 → 分离状态变量和派生属性。
- 错误表现 → 看到解析成功就宣称兼容 → 失败原因 → 实验性特性可能部分实现或行为不一致 → 修正方法 → 用浏览器矩阵和视觉回归验证真实结果。
追问及应对
追问一：if() 与 @supports 应该如何选择？
若只需要决定一个属性值，例如颜色格式，if(supports(...)) 可以让值和属性靠近。若要同时改变多个声明、伪元素或布局规则，@supports 更易读，也能集中处理不支持时的整组样式。两者可以组合，但不要把整页逻辑塞进单个 if()。
追问二：两个条件都为真时会发生什么？
按书写顺序选择第一条为真的分支，后续分支不再参与结果。把高优先级或更具体的条件写在前面，并在代码审查中标出互斥假设；否则新增分支可能被前面的通用条件遮蔽。
追问三：如果浏览器不支持 if()，能否依靠 CSS 解析器保留旧值？
可以依靠两条独立声明实现回退：先写稳定值，解析器跳过包含未知函数的第二条声明。不能把旧值和新值写在同一条声明中，也不能假设支持 if() 的浏览器在未命中时自动恢复上一条声明。
追问四：style() 查询导致组件状态难以追踪，怎么办？
建立状态变量的命名空间和唯一 owner，记录它由哪个祖先设置；在 DevTools 中检查计算值和级联来源。若状态需要跨多个组件或改变很多属性，改用显式 class、data 属性或规则级查询，牺牲一点简洁换取可观测性。