题干与适用场景
一个跨浏览器设计系统希望为支持新 CSS at-rule 的浏览器启用更自然的进入动画和视图过渡，同时保留旧浏览器的静态体验。Chrome 官方 Web UI 更新介绍了在 @supports 中检测特定 at-rule 的方向。请设计不影响首屏、可访问性和主题一致性的发布方案。
面试官考察点
面试官考察你是否把“语法识别”与“完整行为可用”区分开，能否设计 CSS 层叠、降级、减少动效偏好、服务端渲染和监控。高质量回答会避免把浏览器名称硬编码为能力判断。
回答前需要澄清的问题
- 增强能力是装饰性动画，还是依赖过渡完成的交互状态？
- 不支持新规则时，最低可接受体验是什么？
- 用户的
prefers-reduced-motion、高对比度和键盘操作如何优先？ - 是否需要覆盖嵌入 WebView、旧版浏览器和 SSR 首屏？
30 秒回答
“我会把基础布局和状态交互写成默认 CSS，再用能力查询为支持的 at-rule 添加增强层。检测只决定是否启用可选样式，不能替代运行时状态和可访问性检查；prefers-reduced-motion 始终优先。旧浏览器得到稳定的无动画路径，支持者得到过渡增强。通过真实浏览器矩阵、视觉回归、键盘操作和首屏指标验证后，再逐步扩大范围。”
分步骤深入解答
1. 定义基础体验
默认层必须包含完整布局、焦点样式、错误反馈和可操作状态，不依赖动画结束事件。组件卸载、路由跳转或网络失败时，内容仍能直接到达目标状态。
2. 分离能力查询与状态选择
把 at-rule 支持判断放在 CSS 能力层，把“是否打开面板”“是否正在离场”等状态放在类名或属性层。能力查询回答浏览器是否能解析规则，状态选择回答组件现在应显示什么，二者不能混为一个浏览器分支。
3. 组织层叠与回退
先加载基础规则，再在 @supports 条件内增加增强规则。增强规则只覆盖必要属性；当解析失败时，未知块应被忽略而不破坏基础样式。避免依赖增强层重置基础层的关键尺寸或颜色。
4. 处理动效偏好
在增强层内继续遵守 prefers-reduced-motion: reduce，将过渡缩短或关闭，并确保焦点、关闭和错误状态仍有明确反馈。不能用“支持 view transition”绕过用户偏好。
5. 覆盖 SSR 与 WebView
首屏 HTML 不应等待客户端检测；服务端输出基础结构，客户端只负责可选增强。测试嵌入 WebView、旧浏览器、部分支持和禁用动画的环境，确认未知 at-rule 不会产生白屏或布局跳动。
6. 验证与发布
建立浏览器与功能矩阵，做视觉回归、键盘/屏幕阅读器测试、CLS/LCP 对比和错误日志采样。先对一个组件或低风险页面灰度；若回归或投诉上升，移除增强层开关即可恢复基础体验。
高质量示范回答
我会先实现不依赖新语法的基础布局、状态和可访问性，再用 @supports 的 at-rule 能力查询增加可选动画。能力查询只判断解析能力，组件状态仍由类名或属性控制；prefers-reduced-motion 优先级更高。SSR 直接输出基础 HTML，增强层失败时被忽略。发布前覆盖旧浏览器、WebView、SSR、键盘和视觉回归，观察 CLS/LCP 与错误反馈；先灰度单个组件，异常时关闭增强开关而不回滚基础路径。
常见错误
- 按浏览器名称分支 → UA 漂移和误判 → 按能力查询。
- 把解析支持当作行为完整 → 部分实现仍有差异 → 做真实浏览器矩阵与回归。
- 增强层覆盖基础尺寸 → 不支持时布局破坏 → 增强规则只覆盖可选属性。
- 忽略减少动效偏好 → 用户体验受损 → 在增强层再次处理媒体查询。
- 让首屏等待客户端检测 → 白屏或布局跳动 → SSR 先输出基础体验。
追问及应对
@supports 返回支持就能放心使用吗？
不能。它只说明解析器接受条件，需要在目标浏览器验证具体 at-rule、事件时序和降级路径。
为什么不直接删除旧 CSS？
新能力可能在 WebView、企业浏览器或辅助技术环境中缺失。基础层是可靠的长期契约，增强层应可独立撤销。
如何测试减少动效？
在自动化和人工测试中启用 prefers-reduced-motion: reduce，确认动画缩短或取消后，焦点、状态和关闭操作仍清晰可见。
何时可以把增强设为默认？
当目标环境覆盖、视觉与可访问性回归、性能指标和错误率达到门槛，并且仍保留基础回退时，才可扩大默认范围。