CSS 布局与格式化上下文体系

• Flex 子项默认自动最小尺寸 min-width:auto 由内容决定
• min-width:0 解除最小尺寸约束使子项可收缩
• overflow hidden 与 white-space nowrap 是省略号生效前提

Flex 子项的默认最小尺寸是 min-width:auto，其自动最小值由内容（如长文本）决定，导致子项无法收缩到内容宽度以下；而 text-overflow: ellipsis 依赖元素实际宽度被压缩到小于内容宽度，因此省略号失效。将子项设置为 min-width: 0 后，允许其收缩到 0，再配合 overflow: hidden 与 white-space: nowrap，省略号即可正常出现。Grid 子项同样适用。工程上建议在可伸缩的列表项、导航项上显式声明 min-width: 0，避免内容撑破弹性布局。

考察 Flex 自动最小尺寸这一高频布局坑，理解 min-width:auto 与 overflow 的相互作用即可定位省略号失效根因。答题时应先说明省略号生效三前提，再点出自动最小尺寸是失效根因，最后给出修复，形成由现象到原理的分析链路。

• content-visibility:auto 跳过离屏元素的渲染工作
• 跳过渲染时元素无固有尺寸会导致滚动跳动
• contain-intrinsic-size 提供占位尺寸稳定滚动条

content-visibility: auto 会让离屏元素的布局与绘制被跳过以提升渲染性能，但被跳过时浏览器无法计算元素的真实尺寸，滚动条高度与滚动位置会随之跳动。contain-intrinsic-size 为元素声明一个近似固有尺寸，使浏览器在跳过渲染时仍能稳定占位，如 contain-intrinsic-size: auto 500px，其中 auto 表示有实际尺寸时用实际值、无实际尺寸时用回退值。该能力常用于长列表、虚拟滚动占位与图片懒加载场景，保证首屏渲染加速的同时滚动体验稳定。

考察 content-visibility 的性能收益与副作用，核心是理解跳过渲染仍需保留尺寸这一设计意图，是长列表优化类题目的常见考点。注意区分 auto 关键字语义：有实际尺寸时用实际值、被跳过时用回退值；面试时可结合虚拟列表首屏空白与滚动条抖动两个现象说明其必要性。

• BFC 常见触发条件：float、绝对定位、overflow 非 visible 等
• IFC 由包含行内级盒的块容器建立
• Flex/Grid 建立独立布局上下文决定子项排列

IFC（行内格式化上下文）由包含行内级盒的块容器建立；BFC（块级格式化上下文）的常见触发条件包括根元素、float、绝对/固定定位、display:inline-block/table-cell/flex/grid、overflow 非 visible 等。BFC 内部布局与外部隔离，可用于解决外边距折叠、浮动塌陷与清除浮动。Flex 容器建立 flex formatting context，直接子项成为 flex item，按主轴与交叉轴对齐；Grid 容器建立 grid formatting context，子项按行列轨道定位。三者上下文互斥，共同决定子项的排列与尺寸算法。

考察格式化上下文体系的基础概念，答清 BFC 触发条件与 Flex/Grid 上下文差异即可覆盖考察意图，属布局基础必考题。补充记忆点：flex/grid 容器既触发 BFC 又建立自身格式化上下文；回答时按触发条件、隔离作用、与 Flex/Grid 差异三层展开更清晰。

• 同一 BFC 内相邻块级盒的垂直外边距取较大值合并
• 父子外边距也会折叠
• BFC、border/padding、浮动等条件阻止折叠

同一 BFC 内相邻块级盒的垂直外边距会取较大值合并，父元素与第一个/最后一个子元素的垂直外边距也会向外折叠。阻止折叠的常见条件包括：父元素建立 BFC（如 overflow: hidden）、父子之间有 border 或 padding 隔开、子元素浮动或绝对定位、父子之间插入非空内容、外边距为负值等。工程上常用 padding 替代 margin 或为父容器建立 BFC 来隔离，保证组件间距稳定可预期，避免子元素外边距穿透到父元素之外造成布局错乱。

考察外边距折叠的经典规则，重点是同一 BFC 内相邻垂直边距合并的发生条件与隔离手段，属 CSS 布局高频基础题。注意折叠取较大值在负外边距时变为相加；回答时给出 overflow、padding、border、浮动等阻断条件，并说明工程上用 padding 替代 margin 的常见做法。

• content-box 的 width 只表示内容宽度
• border-box 的 width 包含 padding 与 border
• 全局 border-box 便于百分比与栅格布局计算

在 content-box 下，width 只表示内容区宽度，元素实际占位还需加上 padding 与 border；在 border-box 下，width 包含内容、padding 与 border，声明宽度即最终宽度。当元素宽度为百分比且 padding 固定时，content-box 会导致总宽超出容器而需额外换算，border-box 则符合直觉、易于维护。工程上通常用 * { box-sizing: border-box } 全局重置，使设计稿尺寸、栅格列宽与响应式布局的计算保持一致，减少盒模型相关的偏移与溢出问题。

考察盒模型核心概念与 box-sizing 的工程选择，答出两种模型的宽度计算差异与全局重置的原因即可，属必考基础题。可补充百分比宽度加固定 padding 时 content-box 溢出容器的例子，说明 border-box 在栅格与响应式布局中减少换算的实际收益。

• :is/:not 取参数列表中最高的特异性
• :where 特异性恒为 0 适合做零权重复位
• :has 支持父选择并取参数最高特异性

:is() 与 :not() 的特异性取参数列表中特异性最高的一项；:where() 的特异性恒为 0，适合承载复位与基础样式，方便被组件样式低成本覆盖。:has() 同样取参数的最高特异性，同时提供父选择与前置兄弟选择能力，可基于子元素状态影响祖先样式。合理组合这些选择器，可显著降低选择器深度与 !important 使用量，让覆盖规则可预测、便于维护，是大型样式系统治理特异性的重要手段。

考察新一代选择器的特异性计算规则，记住 :is/:not 取最高、:where 归零、:has 可反向选择三个结论即可答对。注意 :is/:not 取参数最高特异性、:where 归零的对比是核心得分点，可结合基础样式库覆盖场景说明零权重选择器的工程价值。

• 原生嵌套需用 & 显式引用父选择器
• 主流浏览器已原生支持，也可经编译降级
• 预处理器仍保留变量、混合宏等高级能力

原生 CSS Nesting 使用 & 引用父选择器，如 .card { & .title { ... } }，Chrome 112+、Safari 17.2+、Firefox 117+ 等主流浏览器已支持，也可经 Lightning CSS 等工具编译降级到旧浏览器。与 SCSS/Less 相比，原生嵌套不能隐式拼接后代选择器、不提供变量与混合宏等语言特性，但可减少预处理器依赖、提升源码可读性。工程上可渐进采用原生嵌套处理简单层级，同时保留预处理器处理变量、函数、混合宏等能力，避免重复劳动。

考察原生 CSS 嵌套的语法边界与浏览器支持矩阵，以及与预处理器能力边界的对比，属于现代 CSS 工程化题。回答时区分原生嵌套的 & 显式语法与 SCSS 隐式拼接差异，并说明新旧浏览器并存时的编译降级策略，体现工程落地意识。

• 自定义属性沿 DOM 树继承
• :root 定义即全局可见，中间元素可覆盖形成作用域
• var() 计算时展开，未定义时使用回退值

自定义属性会像普通 CSS 属性一样沿 DOM 树从祖先继承到后代，在 :root 上定义即全局可见；但任何中间元素重新赋值都会覆盖后代的取值，从而形成组件级作用域。var() 在计算值时展开，未定义时使用回退值。需要注意的是，自定义属性不参与动画插值等特殊机制，且媒体查询无法直接按变量值分支，因为媒体查询基于视口等环境条件而非变量。工程上常用 :root 定义全局令牌、组件根节点覆盖局部值，实现主题与设计系统化。

考察自定义属性的继承语义与 :root 全局变量的作用域边界，是主题化与设计系统面试中的高频基础点。注意自定义属性无法在媒体查询中按值分支；回答时可对比 JS 修改变量的运行时主题方案，说明 :root 全局与组件级覆盖的分层用法。

• :has() 选择包含指定后代的祖先
• 支持兄弟关系表达与行高亮
• 复杂 :has 存在性能开销需控制

:has() 允许选择包含指定后代的祖先元素，例如 .card:has(img:hover) 可在图片悬停时联动整卡样式；表格中 tr:has(input:checked) 可高亮选中行；:has(+ .x) 还能表达后随某元素的前置兄弟关系。Chrome 105+、Safari 15.4+、Firefox 121+ 已全平台支持，纳入 Baseline。由于浏览器需要反向匹配候选元素，复杂 :has() 有一定性能开销，应避免在超大列表中叠加多层 :has，必要时用 JS 状态类替代。

考察 :has() 的父选择能力与工程化用法，给出典型场景并指出性能边界，可体现对现代 CSS 能力的掌握。给出至少两个典型场景（卡片 hover 联动、表格行选中高亮）并说明反向匹配的性能代价，展示既会用又懂边界的工程能力。

• !important 提升到最高优先级组
• 级联层中 important 反转层顺序
• 团队规范：最后手段而非常规工具

普通声明按来源、层、特异性、出现顺序级联，!important 声明整体提升到最高优先级组。特殊之处在于 @layer 中，!important 会反转层的优先级顺序：后声明的层中 important 反而优先级更低。内联样式可被外部 !important 覆盖，而 !important 内联样式优先级最高。工程上应把 !important 视为最后手段，优先通过级联层、特异性控制与命名规范解决冲突，并约定禁止滥用，避免出现难以排查的样式覆盖问题。

考察 !important 与级联层、内联样式的相互作用及团队规范，难点是层内 important 顺序反转这一反直觉规则。记忆点：普通声明按来源、层、特异性、顺序级联，important 提升到最高组且层内顺序反转；回答时补充团队规范视角更完整。

• 特异性按 ID/类/类型三元组计数
• 同级特异性下后出现者生效
• 继承样式优先级最低不参与比较

特异性按 (a, b, c) 三元组计算：a 为 ID 选择器个数，b 为类、属性与伪类选择器个数，c 为类型选择器与伪元素个数，依次比较 a、b、c，数值大者胜出。同特异性下后出现者生效；!important 声明优先于普通声明。继承样式不参与特异性比较，优先级低于任何直接命中元素的规则。:is/:not 取参数列表最高特异性、:where 归零是常见变体。工程上保持特异性扁平，如 BEM 命名，避免深层嵌套导致覆盖困难。

考察特异性三元组计算与级联顺序，是 CSS 基础必考题，答清计数规则与继承优先级即可得分。建议按 (a,b,c) 三元组口述计算过程，说明继承样式不参与比较、同特异性按出现顺序，最后给出 BEM 保持低特异性的实践建议。

• :invalid 在无效状态一出现即匹配
• :user-invalid 要求用户已交互后才匹配
• 避免页面初始即出现大量错误样式

:invalid 只要元素处于无效状态就立即匹配，即使页面刚加载也会触发，容易在用户尚未操作时就显示大量错误样式，造成噪音。:user-invalid 要求用户已经尝试交互，如输入、失焦或提交之后才匹配，符合先体验后提示的原则，显著改善表单初始体验。:user-valid 同理在用户交互后才标记有效。工程上可用 :user-invalid 搭配 input[type=email] 等原生约束验证实现零 JS 错误提示，再结合 :focus 精确定位当前字段，减少无效状态误报。

考察 :user-invalid 与 :invalid 的触发时机差异及其在表单体验上的价值，属表单校验样式题。对比 :invalid 的即时匹配与 :user-invalid 的交互后匹配，强调避免初始表单全红的设计意图，可结合原生校验伪类零 JS 实现说明。

• :placeholder-shown 匹配占位符可见即值为空
• :not(:placeholder-shown) 表示已有输入
• 与校验状态组合实现空态不报错

当输入框值为空且占位符可见时，:placeholder-shown 匹配；一旦输入内容，占位符隐藏，:not(:placeholder-shown) 命中，可据此实现有值状态样式，如 label 上浮、边框变色。与 :user-invalid 组合可实现：用户已交互且值无效时显示红色提示，而空值状态（:placeholder-shown）不报错，避免初始态与空态误报。三态组合（空、有效、无效）可覆盖完整表单反馈，配合 CSS 自定义属性可进一步统一主题样式。

考察表单状态选择器的组合用法，重点理解 :placeholder-shown 与空值的映射关系及状态组合顺序。梳理空态、有效、无效三态的组合写法，注意 :placeholder-shown 仅在有占位符时有意义，回答时给出 label 上浮等典型交互。

• :focus 在元素获得焦点时总是匹配
• :focus-visible 只在浏览器判定需要可见焦点时匹配
• 避免鼠标点击产生多余的焦点环

:focus 在元素获得焦点时始终匹配，鼠标点击和键盘 Tab 都会命中，容易在鼠标操作时显示多余焦点环。:focus-visible 只在浏览器根据输入方式与交互上下文判定需要可见焦点时匹配：键盘导航时匹配，鼠标点击时通常不匹配，从而兼顾可访问性与视觉整洁。实践中建议默认使用 :focus-visible 定义焦点样式，同时保留 :focus 样式作为不支持该伪类的旧浏览器回退，确保键盘用户始终能看到清晰的焦点指示。

考察 :focus-visible 与 :focus 的触发差异及其对键盘导航的意义，是无障碍与表单交互高频题。强调键盘导航与鼠标点击的输入方式差异，建议默认用 :focus-visible 并保留 :focus 回退，可补充焦点环对比度与偏移细节。

• 普通自定义属性仅继承字符串值，无类型信息
• @property 注册初始值、语法与继承性
• 注册后可参与类型校验与动画插值

普通自定义属性只按字符串保存与继承，浏览器不知道其值类型，无法参与属性动画插值，未定义时取 inherit 或回退值。@property 可以注册自定义属性，声明语法类型（如 、 、）、初始值与是否继承，注册后浏览器能对值做类型校验，并支持在 transition 与 animation 中插值。差异的关键在于类型系统：注册属性让自定义属性从纯字符串变量升级为可计算的类型化属性，是实现渐变动画、进度环等场景的基础。

考察 @property 注册的类型化能力与普通自定义属性的本质差异，重点在类型、初始值与动画插值三方面。核心对比是普通变量无类型、注册变量有 syntax/initial-value/inherits 并可插值；回答时给出渐变旋转等动画示例更能说明价值。

• :has() 接受相对选择器列表作为参数
• Chrome 105+/Safari 15.4+/Firefox 121+ 支持
• Baseline 意味着主流浏览器稳定可用

:has() 接受一个相对选择器列表作为参数，选择满足条件的祖先或兄弟元素，例如 .card:has(> .badge) 匹配包含直接子徽标的卡片，.title:has(+ p) 匹配后随段落的标题。Chrome 105+、Safari 15.4+、Firefox 121+ 均已支持，符合 Baseline 标准，即主流浏览器中稳定可用，可放心在生产环境使用。它填补了 CSS 长期缺少父选择器的空白，配合 :is/:where 可简化大量 JS 状态类与嵌套结构。

考察 :has() 的语法形态与浏览器支持现状，Baseline 判断是近年浏览器兼容性考察的新方向。说明 Baseline 指主流浏览器稳定可用；回答时给出 :has() 祖先选择与兄弟选择两种语法形态，体现对语法模型的完整理解。

• anchor-name 为锚点元素命名
• position-anchor 声明目标锚点
• position-area 用逻辑区域定位与回退

Anchor Positioning 允许普通元素相对页面中任意锚点元素定位，无需 JS 计算坐标。锚点元素通过 anchor-name: --tip 命名，被定位元素通过 position-anchor: --tip 声明关联锚点，再配合 position-area 或 inset-area 指定相对锚点的区域，如 position-area: top center 表示锚点上方居中。还支持 anchor() 函数精细控制偏移，并可用 position-try-fallbacks 处理视口边缘翻转回退。它取代了 tooltip、popover、菜单等场景中依赖 JS 测量与 ResizeObserver 的定位方案。

考察 Anchor Positioning 的核心属性与定位模型，重点区分锚点命名、关联与区域定位三层关系。理清 anchor-name 命名、position-anchor 关联、position-area 区域三层关系，并补充 position-try-fallbacks 翻转回退与支持现状。

• subgrid 继承父网格的轨道定义
• 子网格与其父网格轨道对齐
• 避免多层嵌套 Grid 尺寸错位

普通嵌套 Grid 的子容器使用独立轨道系统，内部行高与父网格不对齐，跨组件对齐需要手动同步尺寸。Subgrid 允许子网格继承父网格的轨道定义：grid-template-columns: subgrid 表示列轨道直接复用父网格的列，行同理，从而让嵌套内容与父网格逐列逐行对齐。它特别适合表头与表体、卡片组、仪表盘等需要多行多列严格对齐的场景。支持上 Chrome 117+、Safari 16+、Firefox 71+ 均已可用。

考察 Subgrid 继承父轨道的能力及其与独立嵌套 Grid 的差异，是 Grid 进阶高频考点。强调 subgrid 复用父网格轨道而非创建新轨道；回答时说明表头表体、卡片行分区等必须对齐的场景，并给出支持版本矩阵。

• grid-template-areas 用命名区域描述布局
• 区域网格提供可视化可读性
• 复杂跨行跨列时维护成本与边界

grid-template-areas 用 ASCII 区域名直接描述布局结构，如 header/侧栏/主区/页脚，一眼可读，配合 grid-area 把子元素放入命名区域，适合仪表盘、应用外壳等宏观布局。显式轨道与 grid-column/grid-row 行号定位更精确，适合动态生成的列表与数据网格。边界在于 areas 要求区域构成矩形、不能有孔洞，且布局调整需同步修改模板与子项映射；动态数量或需要程序化控制时，显式轨道更灵活，两者也可混用。

考察 grid-template-areas 的可读性优势与其矩形约束、维护边界，属 Grid 布局选型题。指出 areas 要求矩形无孔洞的约束；回答时对比命名区域适合宏观骨架、显式轨道适合动态数据的选型判断。

• align-items 控制每行内交叉轴对齐
• align-content 控制多行整体在交叉轴的分布
• 单行时 align-content 不生效

align-items 控制每一行内部各 flex item 在交叉轴上的对齐方式（stretch、center、flex-start 等），作用于单个元素；align-content 控制多行 flex 容器中整组行在交叉轴上的分布（flex-start、space-between、center 等），作用于行组。当容器只有一行时，align-content 不生效，只有 align-items 生效；多行（flex-wrap: wrap）时两者叠加：先按行内部对齐，再按行组分布。理解两者层级关系可避免多行卡片组垂直分布不符合预期的错误。

考察 align-items 与 align-content 的层级语义差异，单行多行场景的生效条件是最常见的混淆点。记忆口诀：align-items 管行内、align-content 管行组，单行时 align-content 不生效；多行时先元素对齐后行组分布。

• @container 基于最近容器上下文匹配
• container-type 建立包含上下文
• cqw/cqh 相对容器尺寸而非视口

Container Queries 允许组件根据其最近容器上下文的尺寸而非视口来响应式调整样式。容器元素需声明 container-type: inline-size 建立包含上下文，子元素用 @container (min-width: 400px) 匹配。容器查询单位 cqw（1% 容器宽度）、cqh（1% 容器高度）等相对容器尺寸计算，与相对视口的 vw/vh 有本质区别，适合组件内部以容器为基准的排版。它让组件在不同父容器中独立适配，是组件化与设计系统场景下对媒体查询的补充。

考察容器查询的建立方式与容器单位相对视口单位的差异，体现组件化响应式的理解。强调容器查询单位相对最近容器上下文计算，与视口单位本质不同；回答时给出 container-type 建立上下文的步骤更完整。

• 显式轨道由 grid-template-* 定义
• 溢出项目自动创建隐式轨道
• auto-flow 控制密集与行/列优先放置

显式轨道由 grid-template-rows 与 grid-template-columns 定义，隐式轨道是项目被放置到显式轨道之外时浏览器自动生成的轨道，尺寸由 grid-auto-rows/grid-auto-columns 控制。grid-auto-flow 决定自动放置方向：默认 row 按行填满后换行，column 按列填满后换列，dense 允许回填前面留下的空洞，提高空间利用率但会改变文档顺序的视觉呈现。理解显式/隐式轨道与 auto-flow，可准确预测项目排列，避免隐式轨道尺寸不符合预期。

考察 Grid 显式/隐式轨道的概念与自动放置算法，auto-flow 的放置顺序是重点。说明显式轨道由 grid-template 定义、溢出自动生成隐式轨道，dense 回填会改变视觉顺序，回答时结合自动放置算法举例。

• justify-content 控制主轴对齐，align-items 控制交叉轴
• flex-wrap 换行后形成多行
• gap 统一设置主轴与交叉轴间距

Flexbox 面向一维布局：主轴方向用 justify-content 控制分布，交叉轴方向用 align-items/align-self 控制对齐；flex-wrap: wrap 允许项目换行形成多行，配合 align-content 控制行组分布。gap 属性同时设置主轴与交叉轴间距，替代 margin 负值技巧。Flexbox 不擅长同时约束行与列，复杂二维布局应交给 Grid；两者常结合使用，如 Grid 定整体骨架、Flexbox 做局部组件内的一维排列，各取所长。

考察 Flexbox 一维模型的本质与 gap、换行行为，以及与 Grid 的分工，属布局基础高频题。强调 flex 是一维、grid 是二维的分工，gap 统一间距替代 margin hack，回答时给出两者组合使用的典型布局结构。

• color-gamut 检测色域能力如 p3/rec2020
• dynamic-range-limit 检测 HDR 动态范围支持
• 渐进增强：先 SDR 基础样式再 HDR 增强

color-gamut 媒体查询检测显示设备支持的色域，如 p3、rec2020，用于判断能否安全使用广色域颜色；dynamic-range-limit 检测设备是否支持高动态范围（HDR）输出。工程上应遵循渐进增强：先提供标准 sRGB 与 SDR 样式保证基础可读性，再用 @media (color-gamut: p3) 提供 P3 颜色增强，用 dynamic-range-limit: high 判断是否输出 HDR 效果。同时保留降级路径，避免 HDR 内容在普通屏幕出现发灰、过曝等问题。

考察 HDR 与广色域相关媒体查询的语义及渐进增强策略，属于显示能力适配的现代考题。回答时按渐进增强顺序组织：sRGB 基础、p3 色域增强、HDR 动态范围判断，并说明不支持时的降级策略。

• color-mix 按比例混合颜色生成变体
• relative color 基于已有颜色转换分量
• light-dark 根据 color-scheme 输出明暗色

color-mix(in oklch, var(--primary) 70%, white) 可在设计令牌基础上按比例混合生成 hover、禁用等颜色变体，无需维护大量硬编码色值；relative color 语法如 rgb(from var(--primary) r g b / 0.5) 可提取或变换已有颜色的分量，实现透明化、变亮变暗。light-dark() 根据 color-scheme 自动返回亮色或暗色值，简化明暗双主题。三者结合能减少设计令牌冗余，并在生成变体时保持色彩关系，便于满足可访问对比度要求。

考察现代 CSS 颜色函数的用途差异与组合价值，重点在主题变体生成与明暗主题切换的工程化。区分 color-mix 按比例混合、relative color 按通道变换、light-dark 按配色方案取值三个工具的分工，回答时给令牌派生示例。

• 在 oklch 等感知均匀空间混合
• 按设计令牌动态派生 hover/禁用色
• 减少色板冗余并保持主题一致性

color-mix() 允许在运行时按比例混合两个颜色，如 color-mix(in oklch, var(--primary) 80%, white) 生成浅色变体。实践要点：优先在 oklch 等感知均匀空间混合，避免 sRGB 空间产生的偏色；将混合比例沉淀为设计令牌，保证 hover、按下、禁用等状态色一致；变体随主题令牌自动联动，切换主题时无需重算色板。相比预计算色板，它减少冗余定义、提升可维护性，但要注意浏览器兼容性与关键路径上的颜色计算开销。

考察 color-mix 的工程化用法，重点是色彩空间选择、令牌化与主题联动优势，属现代 CSS 实践题。补充色彩空间选择（oklch 优于 sRGB）与混合比例令牌化的要点，强调主题切换时颜色变体自动联动的维护收益。

• OKLCH 的 L 通道近似人眼感知亮度
• 感知均匀保证等步长插值视觉等距
• culori/chroma.js 可在 OKLCH 中程序化生成色阶

OKLCH 是基于 OKLab 的极坐标色彩空间，其 L（亮度）、C（彩度）、H（色相）三个通道接近人眼感知，相同数值步长对应的视觉差异近似相等，因此在不同亮度、色相间插值不会出现中间色发灰或偏色。设计系统需要生成 50-900 等梯度色阶时，用 culori 或 chroma.js 在 OKLCH 空间按 L/C 步长程序化生成，比手工调色更一致，并能保证跨色相的明度统一，为后续无障碍对比度与主题变体奠定基础。

考察 OKLCH 的感知均匀特性及其在设计系统色阶生成中的应用，属于现代色彩管理考点。可举 culori/chroma.js 生成 50-900 色阶的例子，强调感知均匀空间下等步长插值视觉等距，避免中间色偏灰。

• color-scheme 声明页面支持的配色方案
• 浏览器据此渲染原生控件与默认色
• 配合 prefers-color-scheme 与 CSS 变量实现主题

color-scheme 声明页面支持 light 或 dark 配色，浏览器会据此将表单控件、滚动条、默认背景等 UA 样式切换为对应主题，无需逐一定制。仅声明 color-scheme 时浏览器自动翻转原生控件外观；要完全掌控内容区配色，还需结合 prefers-color-scheme 媒体查询覆盖 CSS 变量，或用 light-dark() 函数按方案取值。若声明 color-scheme: light dark 而内容未适配暗色，可能产生控件深色、背景浅色的割裂，因此需保证内容主题与声明一致。

考察 color-scheme 与原生暗色模式的协同机制及与内容主题的一致性要求，属主题化基础题。回答时区分声明 color-scheme 只改变原生控件外观、内容配色仍需 prefers-color-scheme 覆盖，并提醒两者一致性。

• OKLCH 提供感知均匀的插值与调色
• P3 扩大可显示色域范围
• 结合实现更鲜艳且一致的视觉系统

OKLCH/OKLAB 解决颜色建模问题：其通道感知均匀，使渐变插值、色阶生成与明度统一更符合人眼，避免 sRGB 空间中的灰阶偏色。P3 解决色域问题：相比 sRGB 覆盖更多可显示颜色，广色域设备上能呈现更鲜艳、真实的色彩。设计系统可先在 OKLCH 中定义与插值颜色，再以 P3 色值（如 color(display-p3 ...)）输出增强版本，用 @media (color-gamut: p3) 渐进增强，普通设备回退 sRGB，兼顾一致性、鲜艳度与兼容性。

考察 OKLCH 与 P3 各自解决的问题及组合策略，是现代设计系统色彩选型题。注意 OKLCH 解决颜色建模、P3 解决色域范围，二者不冲突；回答时给出 @media (color-gamut: p3) 渐进增强写法。

• forced-colors: active 在系统强制配色时触发
• 系统色关键字如 CanvasText 保证可见性
• 避免依赖颜色传达信息并保留焦点样式

forced-colors: active 在用户启用系统强制配色（如 Windows 高对比模式）时触发，浏览器会强制页面使用系统配色，忽略大部分作者颜色。适配要点：优先使用系统色关键字（Canvas、CanvasText、ButtonText、LinkText 等）保证文本与控件可见；用 forced-colors 查询微调边框、图标与焦点样式，例如保留 1px 实线边框区分元素；避免仅靠颜色传达状态，同时提供图形与文字辅助。强制配色下作者颜色被覆盖，需保证布局与信息层级仍清晰。

考察 forced-colors 的触发与适配策略，重点在系统色关键字与信息传达的兜底，属无障碍适配题。补充 forced-colors 下作者颜色被系统色替换的事实，回答时强调系统色成对使用与不只靠颜色传达信息的要点。

• reduced-transparency 表示减少透明效果
• reduced-data 表示减少数据流量
• 用媒体查询降级动效与资源加载

prefers-reduced-transparency: reduce 表示用户希望减少透明与毛玻璃等视觉效果，可能因视力或性能原因；前端应降低或移除背景模糊、半透明层，改用不透明底色保证可读性。prefers-reduced-data: reduce 表示用户希望减少数据传输，常见于移动流量受限场景；前端可据此跳过非关键资源，如延迟加载图片、停用遥测上报、提供低带宽占位。两者都是面向用户偏好的媒体查询，通过渐进增强策略在支持浏览器中优雅降级。

考察两类偏好媒体查询的语义与响应方式，属现代可访问性与性能适配题。回答时给出两类偏好的降级示例（去毛玻璃、延迟非关键资源），并说明这些媒体查询属于渐进增强而非必须。

• 系统色关键字映射到强制配色
• Canvas 背景与 CanvasText 前景配对使用
• 避免硬编码颜色导致不可见

forced-colors: active 激活时，浏览器强制使用系统配色，作者声明的颜色被系统色替换，而 Canvas、CanvasText、ButtonFace、ButtonText、LinkText 等系统色关键字会解析为用户当前的强制配色值。正确做法是成对使用：如 background: Canvas 搭配 color: CanvasText，保证文本可读；边框使用 CanvasText 或 ButtonText 以区分区域。注意不要只覆盖前景或背景，也不要假设系统色与任何设计稿一致，信息传达还应辅以图标与文字。

考察 forced-colors 下系统色关键字的成对使用规则，是 Windows 高对比适配的实操细节题。记忆要点：Canvas 与 CanvasText 必须成对出现，边框可用 ButtonText；回答时补充信息传达不能仅依赖颜色的原则。

• color-scheme 表达明暗偏好
• contrast 表达对比度偏好
• forced-colors 是更强的强制配色状态

prefers-color-scheme 表达用户对亮色或暗色主题的偏好，用于主题切换；prefers-contrast 表达对高/低对比度的偏好，可据此增强文字与背景的对比或减弱刺眼效果；forced-colors 表达系统强制配色状态，优先级最强，会覆盖大部分作者颜色。协同策略：先保证默认样式对比度达标，再按 color-scheme 切换主题，按 contrast 微调对比，最后在 forced-colors 激活时使用系统色关键字兜底，确保任何偏好组合下内容都清晰可读。

考察三类偏好媒体查询的语义层级与协同适配策略，属综合无障碍适配题。回答时按优先级从弱到强组织：color-scheme 主题、contrast 微调、forced-colors 强制兜底，体现分层适配思路。

• color-contrast 从候选色中选出对比度达标的颜色
• 基于 WCAG 比率计算
• 与令牌联动自动选择可读前景色

color-contrast() 在多个候选颜色中根据 WCAG 对比度比率选出满足目标（如 AA 或 AAA）且最合适的颜色，例如 color: color-contrast(var(--bg) vs var(--text-dark), var(--text-light)) 会根据背景自动选择对比度足够的前景色。与设计系统令牌协作时，把候选色定义为令牌，函数在运行时按当前背景与目标等级自动决策，减少人工校验。注意支持度与性能：需提供回退声明，并在关键文本上仍进行人工对比度验证，不能完全依赖自动选择。

考察 color-contrast() 的自动对比度选择机制及其与令牌体系协作的边界，属设计系统与无障碍交叉题。说明 color-contrast 需提供回退声明并仍需人工校验，回答时强调自动化辅助而非完全替代人工对比度检查。

• animation-timeline 将动画绑定到滚动进度
• scroll() 指定滚动容器与轴
• animation-range 控制动画启停区间

scroll-driven animations 允许动画进度直接由滚动位置驱动，无需 JS 监听滚动。animation-timeline: scroll(root) 将动画时间线绑定到指定滚动容器的滚动进度；animation-range 声明动画从滚动进度的哪个区间开始到哪个区间结束，如 animation-range: 0 40vh 表示前 40vh 内播放完动画。可配合动画名称、时长与缓动定义视觉反馈。注意动画方向受滚动方向影响，且滚动驱动时间线中 duration 不决定总时长而决定单次循环的映射粒度，理解这一点可避免进度错乱。

考察滚动驱动动画的绑定方式与区间控制，是动画新特性的高频考点。注意滚动驱动时间线中 duration 不决定总时长，回答时说明 animation-range 区间映射与滚动方向对进度的影响。

• Media Queries 基于视口与设备特征
• Container Queries 基于容器尺寸
• cqw/cqh 相对最近容器上下文计算

Media Queries 基于视口、设备方向等全局环境条件匹配，适合页面级响应式；Container Queries 基于元素最近包含上下文的尺寸匹配，适合组件级响应式，使同一组件在不同宽度的父容器中自动调整。使用容器查询单位时，1cqw 等于容器宽度 1%，1cqh 等于容器高度 1%，还有 cqi（内联尺寸）、cqb（块尺寸）等变体；它们必须在容器查询上下文内计算。两者可叠加：外层用媒体查询定页面骨架，内层用容器查询定组件细节。

考察两种查询的适用差异与容器单位的基准，是组件化响应式的核心考点。回答时对比两种查询的匹配基准（视口 vs 容器），并说明 cqw/cqh 只在容器上下文内计算的使用前提。

• @scope 将样式限定在子树范围内
• to() 定义样式不再生效的边界
• 避免组件样式泄漏并简化特异性

@scope 允许把样式规则限定在指定根元素的后代范围内，例如 @scope (.card) { .title { ... } } 中 .title 只匹配 .card 内的标题，降低组件样式泄漏与特异性对抗。donut scope 用 to() 指定边界：@scope (.card) to (.card__content) 表示规则作用于 .card 下、但不包括 .card__content 子树的范围，形成环状限域，适合限定头部、脚注等局部区域。该特性已纳入 Baseline，主流浏览器可用，是组件化样式隔离的新选择。

考察 @scope 的限域机制与 donut scope 的边界语义，是样式隔离方向的新考点。说明 donut scope 的 to() 边界含义与隔离强度弱于 Shadow DOM，回答时补充主流浏览器支持现状与降级。

• container-type 建立包含上下文
• container-name 为容器命名以便精确匹配
• @container 按容器尺寸条件应用样式

container-type: inline-size 或 size 将元素标记为查询容器，使其后代可以基于它的尺寸响应式变化；container-name 为容器命名，如 container-name: sidebar，@container sidebar (min-width: 400px) 则精确匹配指定容器的尺寸条件，避免多个嵌套容器竞争。未命名时 @container 匹配最近的容器上下文。还需注意，被查询容器的尺寸不能依赖其自身内容（否则形成循环），工程上常把容器查询用于布局骨架与卡片组件。

考察容器查询三个核心声明的关系与匹配规则，属现代 CSS 组件化考点。注意容器尺寸不能依赖自身内容否则循环，回答时说明 container-name 解决多嵌套容器匹配歧义的用法。

• Sec-Fetch-Site 标识请求来源站点关系
• Sec-Fetch-Mode/Dest 标识请求模式与目标
• 服务端据此拒绝跨站异常请求

Fetch Metadata 是一组由浏览器自动附加的请求头：Sec-Fetch-Site 表示请求者与目标站点的关系（same-origin、same-site、cross-site、none），Sec-Fetch-Mode 表示请求模式（navigate、cors、no-cors 等），Sec-Fetch-Dest 表示请求目标（document、script、image 等）。服务端可按此实施来源校验，例如拒绝 cross-site 且非导航的敏感接口请求、拒绝 mode: no-cors 的写操作，形成纵深防御。实践中需为不支持该头的旧客户端保留宽松回退，并避免对跨站合法资源（CDN、第三方登录）误伤。

考察 Fetch Metadata 头语义与基于来源校验的纵深防御实践，属服务端协作的安全考点。回答时强调这些请求头由浏览器自动附加、难以伪造，并说明旧客户端需宽松回退，避免误伤合法跨站资源。

• CORS 允许跨域读取资源
• CORP 声明资源仅允许同源/同站加载
• CORP 是 CORS 之外的服务端防御层

CORS（Cross-Origin Resource Sharing）决定浏览器是否允许网页跨域读取资源，通过 Access-Control-Allow-Origin 等响应头声明许可；CORP（Cross-Origin Resource Policy）通过 Cross-Origin-Resource-Policy 响应头声明资源只允许 same-origin、same-site 或 cross-origin 加载，是独立于 CORS 的防御层，可阻止其他站点嵌入或读取资源，降低 Spectre 类侧信道风险。配置边界：开放资源设为 cross-origin，私有资源设为 same-origin，二者配合实现最小暴露。

考察 CORP 与 CORS 的互补定位与服务端响应头配置，属 Web 安全基础题。补充 CORP 在降低 Spectre 侧信道风险上的作用，回答时给出三种取值场景（私有 same-origin、开放 cross-origin）。

• @layer 按声明顺序决定层优先级
• 未分层样式优先级高于所有层
• 可用 @layer 重构第三方样式覆盖

级联层通过 @layer 声明，层之间的优先级由首次声明顺序决定：后声明的层优先于先声明的层，例如 @layer base, components 表示 components 覆盖 base。未放入任何层的样式优先级最高，可覆盖所有分层样式，常用于应用级覆写。!important 在层内会反转该规则。工程上常用 @layer reset, base, components, utilities 重构样式架构，将第三方库样式放入低优先级层，避免依赖特异性与 !important 硬覆盖。

考察级联层的优先级顺序与未分层样式的关系，是 CSS 架构管理新考点。记忆点：层顺序按首次声明决定、未分层样式最高；回答时给出 @layer reset, base, components 的典型分层架构。

• sticky 相对最近滚动容器定位
• 父元素 overflow 非 visible 会变成滚动容器
• sticky 只能在父元素范围内移动

position: sticky 元素相对其最近的滚动容器（scrolling box）定位，并在其包含块范围内粘滞。若祖先元素设置 overflow: hidden、auto 或 scroll，该祖先会成为新的滚动容器，sticky 将相对它而非页面视口定位；当父元素 overflow: hidden 且自身不滚动时，sticky 元素会随父元素一起滚动或直接失效，表现为没有吸附效果。解决方法是把 overflow: hidden 移到不影响 sticky 的元素上，或确认最近的滚动容器确实是预期的滚动父级。

考察 sticky 的滚动容器判定与 overflow 对它的影响，是定位场景的高频坑题。回答时先确认最近滚动容器再排查 overflow 祖先，说明 sticky 吸附范围受包含块限制，必要时调整 overflow 位置。

• BEM 用扁平类名控制特异性
• CSS Modules 用局部化类名隔离
• @layer 提供全局层优先级而非命名隔离

BEM 通过扁平化类名把特异性控制在单类水平，冲突靠命名语义解决；CSS Modules 编译生成哈希类名，从命名空间上隔离组件样式。@layer 则从优先级管理维度补充：把第三方库、基础样式放入低优先级层，业务样式放入高层，即使特异性相同也能按层决定胜负，减少 !important。协同边界：@layer 不解决类名冲突与命名泄漏，BEM/CSS Modules 不解决跨来源覆盖顺序，三者可组合使用，形成命名隔离加层优先级的双层治理。

考察层优先级机制与既有样式方案的分工，属样式架构治理题。回答时按命名隔离与优先级编排两个维度说明三者分工，强调组合使用而非互相替代的治理思路。同时注意与 Flex/Grid 上下文记忆时避免混淆触发条件。

• auto-fill 保留空轨道
• auto-fit 折叠空轨道让列拉伸
• 二者均按最小列宽自动换行

repeat(auto-fill, minmax(200px, 1fr)) 会创建尽可能多的轨道并保留空轨道，即使项目较少，轨道宽度仍按 1fr 分配，可能出现右侧空列；repeat(auto-fit, ...) 会折叠空轨道，让现有项目拉伸填满整行。选择边界：需要保持占位或对齐（如骨架屏）时用 auto-fill；希望项目铺满容器宽度时用 auto-fit。二者都要求配合 minmax 定义最小列宽，否则轨道数量无法随容器宽度自适应。

考察 auto-fill 与 auto-fit 对空轨道的不同处理，是响应式 Grid 列布局的经典考点。给出占位对齐场景选 auto-fill、铺满场景选 auto-fit 的判断依据，并强调 minmax 最小列宽的必要性。

• position + z-index 形成层叠上下文
• transform/opacity/filter 等也形成上下文
• z-index 只在同层级上下文内比较

层叠上下文由以下条件形成：定位元素且 z-index 非 auto、flex/grid 子项且 z-index 非 auto、transform、opacity 小于 1、filter、will-change、contain、混合模式等。形成后，其内部子元素的 z-index 只在该上下文内比较，无法与外部元素跨上下文比较，这就是 z-index 看似失效的原因。工程上常因 transform 或 opacity 动画意外创建上下文，导致弹层被遮挡，需检查祖先是否形成层叠上下文并调整层级结构。

考察层叠上下文的形成条件与 z-index 的比较边界，是定位与弹层问题的高频考点。回答时列出常见形成条件并解释 z-index 只能在同上下文内比较，建议检查 transform/opacity 等隐藏上下文。

• composes 引用其他类复用规则
• 支持从其他文件导入复用
• 运行时无额外开销但调试困难

CSS Modules 的 composes 允许一个类组合复用另一个类的规则，如 .btn-primary { composes: btn; }，编译后两个类同时作用于元素；composes 还支持从其他文件引入，如 composes: btn from './btn.module.css'，实现跨文件样式复用。与 Sass @extend 相比，composes 不生成选择器嵌套，规则合并到元素上，避免了特异性膨胀。限制在于 composes 只能组合类选择器、不能用于组合后的样式覆盖，且调试时类名是哈希，需靠 sourcemap。

考察 composes 的复用机制及其与 @extend 的差异，属组件库样式工程题。对比 composes 与 @extend 的生成机制差异，回答时说明 composes 仅组合类选择器且依赖方向需治理。

• 免去 JS 测量与 ResizeObserver
• position-area 声明相对锚点的区域
• Chrome/Safari/Firefox 支持进展

传统 tooltip 定位需要 JS 测量锚点与弹层尺寸、监听滚动与窗口变化，代码繁琐且易抖动。CSS Anchor Positioning 通过 anchor-name 命名锚点、position-anchor 关联、position-area 指定相对区域，如 position-area: top center，声明式完成定位；配合 position-try-fallbacks 在空间不足时自动翻转。工程价值在于减少测量代码、提升稳定性。支持上 Chrome 125+ 已可用，Safari 与 Firefox 逐步跟进中，生产使用需结合特性检测与降级方案（如默认 static 定位）。

考察 Anchor Positioning 在 tooltip 场景的工程价值与支持现状，属现代定位方案题。补充 position-try-fallbacks 翻转与特性检测降级，回答时说明该方案减少 JS 测量代码的工程收益。

• balance 均衡多行文本宽度
• pretty 优化断行避免孤行
• text-wrap-mode 控制是否换行，text-wrap 是缩写

text-wrap: balance 让标题等多行文本的行宽尽量均衡，减少视觉参差，适合短文本标题；text-wrap: pretty 优化长段落断行，减少孤行与坏点，适合正文。两者都会增加少量排版计算成本，balance 应限于有限行数的标题。text-wrap 是 text-wrap-mode 与 text-wrap-style 的缩写：text-wrap-mode 控制是否允许换行，text-wrap-style 控制换行质量。工程取舍：短标题用 balance，长正文用 pretty，必要时在移动端关闭以控制性能。

考察文本换行优化属性的语义分工与性能边界，属排版体验题。注意 balance 限于短标题、pretty 适合正文的性能边界，回答时说明 text-wrap 是 mode 与 style 的缩写关系。

• 跳过离屏元素布局与绘制
• 无尺寸时滚动跳动
• auto 形式在元素可见时恢复正常渲染

content-visibility: auto 会让离屏元素的布局、绘制与包含工作被跳过，从而显著降低长列表首屏的渲染成本，元素进入视口时才正常渲染。由于跳过渲染后元素没有固有尺寸，必须配合 contain-intrinsic-size 提供近似占位尺寸，否则滚动条高度与滚动位置会跳动。写法如 content-visibility: auto; contain-intrinsic-size: auto 200px。优化效果与列表元素复杂度相关，适合卡片流、评论列表等重复结构，对虚拟滚动之外的长列表是低成本加速手段。

考察 content-visibility 的优化原理与占位尺寸配合，是长列表性能优化题。回答时说明 content-visibility 跳过后无尺寸导致滚动跳动，contain-intrinsic-size 提供占位，二者必须成对使用。

• 静态/相对定位以父内容盒为包含块
• 绝对定位以最近定位祖先的 padding 盒为基准
• 固定定位以视口为包含块

包含块决定元素的尺寸百分比与定位偏移的基准。普通流与相对定位元素的包含块是父元素的内容盒；绝对定位元素的包含块是最近的 position 非 static 祖先的 padding 盒（注意是 padding 盒而非内容盒）；固定定位元素的包含块一般是视口，除非祖先有 transform 等形成包含块。transform、filter、will-change 会创建新的包含块，导致 fixed 元素相对该祖先定位，这是弹层定位异常的重要原因。理解包含块即可准确推导偏移与百分比尺寸。

考察包含块的计算规则与定位基准，是定位体系的核心基础题。注意绝对定位以 padding 盒为基准、transform 会改变 fixed 包含块，回答时按定位方式分别说明偏移基准。

• @supports 检测属性与选择器支持
• 用于渐进增强提供增强样式
• 注意支持但行为有差异的情况

@supports 允许按浏览器能力条件化应用样式，如 @supports (display: grid) { ... } 或 @supports selector(:has(a)) { ... }。典型用法是渐进增强：先书写所有浏览器都支持的基础样式，再用 @supports 为支持新特性的浏览器叠加增强效果，如容器查询、子网格、:has 等；不支持时自动回退基础样式。注意 @supports 检测的是语法解析能力而非行为正确性，个别属性支持但失效的情况需结合实机验证，且不宜用它检测每个新特性导致代码膨胀。

考察 @supports 的检测机制与渐进增强用法，属特性检测与兼容策略题。回答时强调基础样式先行、@supports 叠加增强，并说明其检测的是语法支持而非行为正确性。

• :defined 匹配已注册的自定义元素
• 未定义元素可用 :not(:defined) 隐藏
• 避免未升级元素闪烁（FOUC）

自定义元素（custom element）在调用 customElements.define 之前处于 undefined 状态，:defined 匹配已定义的元素，:not(:defined) 匹配尚未定义的。样式上常对未定义元素做占位处理，如 opacity: 0 或隐藏其内部内容，等元素升级后再显示，避免布局闪烁与未渲染内容的闪现。配合 :defined 还可以对升级前后应用不同样式，如加载动画。该能力让自定义元素体系在异步加载组件时保持视觉稳定，是 Web Components 工程的细节考点。

考察 :defined 的语义与自定义元素升级流程的样式配合，属 Web Components 样式题。回答时说明 :defined 与 customElements.define 升级时机的关系，给出 :not(:defined) 占位隐藏避免闪烁的写法。

• :scope 匹配当前作用域根元素
• 邻近度表示选择器与目标元素的就近程度
• @scope 中近的规则优先于远的规则

:scope 匹配当前样式作用域的根元素，例如 @scope (.card) 内 :scope 指 .card 本身，也可用于 querySelector 等 DOM API 中表示查询起点。级联邻近度（cascade proximity）是 @scope 引入的级联概念：同一层且特异性相同时，选择器与目标元素越近（即从作用域根到目标经过的层级越少）优先级越高。因此 @scope 内深层规则可能被更近的浅层规则覆盖，形成按邻近度而非单纯出现顺序的覆盖规则，需要理解以避免样式冲突。

考察 :scope 语义与 @scope 的邻近度优先级规则，是 CSS 作用域新特性的进阶题。注意邻近度只在同层同特异性时参与比较，回答时说明 :scope 匹配作用域根、就近规则优先的覆盖语义。

• = 精确匹配属性值
• ^= 前缀匹配、$= 后缀匹配、*= 包含匹配
• ~= 空格分隔词匹配、|= 连字符前缀匹配

属性选择器中，[attr=v] 精确匹配；[attr~=v] 匹配以空格分隔的词列表中的词；[attr|=v] 匹配等于 v 或以 v- 开头；[attr^=v] 前缀匹配；[attr$=v] 后缀匹配；[attr*=v] 任意位置包含。典型场景：a[href^=https] 标记外链、img[src$=.webp] 按文件类型处理、[lang|=zh] 匹配 zh-CN 等语言、[class~=selected] 匹配类列表中的词。属性选择器不增加类依赖，适合对动态属性与数据属性做样式映射。

考察属性选择器的匹配语义与典型应用，属选择器基础题。回答时按前缀、后缀、包含、词列表、连字符前缀五类匹配逐一举例，说明属性选择器适合动态属性与数据属性。再补充数据属性驱动样式的典型业务场景即可。

• 四元组分别对应内联/ID/类/类型计数
• 嵌套加深导致特异性累积
• BEM 与扁平选择器保持低特异性

特异性四元组 (a, b, c, d) 中 a 表示内联样式，b 为 ID 选择器数，c 为类、属性、伪类数，d 为类型与伪元素数，依次比较。过度嵌套会让 c、d 计数累积，特异性越来越高，后续覆盖只能继续增加选择器长度，形成维护噩梦。工程实践：使用 BEM 等扁平命名把选择器控制在单类水平；避免无意义的祖先链（如 .nav .nav-item .nav-link）；用 :where() 归零基础样式特异性；用 @layer 按层管理优先级。目标是把特异性保持可预测、易覆盖。

考察特异性四元组计数与工程防嵌套策略，是样式可维护性的经典题。说明四元组中内联最高、ID 次之，回答时给出 BEM 与 :where 两种降特异性手段，体现工程治理意识。

• :is() 取参数最高特异性
• :where() 特异性归零
• 取舍取决于覆盖需求

:is() 与 :where() 都能让复杂选择器列表更紧凑，如 :is(h1, h2, h3) 代替三个选择器。差异在特异性：:is() 取参数列表中最高特异性，:where() 恒为 0。取舍策略：需要保证规则不被低特异性规则覆盖、或希望选择器与展开写法等价时用 :is()；希望规则易于被组件样式覆盖、作为基础/复位样式时用 :where()。二者常结合使用，例如 :is() 组织状态、:where() 承载低权重基础样式，兼顾可读性与覆盖灵活性。

考察 :is/:where 的特异性差异与使用场景取舍，属选择器进阶题。回答时用覆盖需求决定选择器：需保证不被覆盖用 :is，需易覆盖用 :where，二者常组合使用兼顾可读性。

• 伪元素内容默认不进入可访问性树
• content 生成的内容不朗读
• 重要信息应放入真实 DOM

::before 与 ::after 生成的 content 默认属于装饰性内容，不会进入可访问性树，屏幕阅读器通常不朗读。因此纯装饰性的图标、分隔线适合用伪元素承载；但承载语义信息的内容（如按钮提示、必填标记）若只放在 content 中，辅助技术用户将无法感知，应放入真实 DOM 文本或用 aria-label 补充。同时注意 content 中的文本在不同浏览器对朗读的支持有差异，工程上遵循装饰用伪元素、语义用真实内容的原则。

考察伪元素内容与可访问性树的边界，属无障碍细节题。回答时强调伪元素内容不进可访问性树，语义信息必须放真实 DOM 或用 aria-label 补充的边界原则。回答时还可说明 content 与 DOM 内容的职责划分。

• 收益：减少重复父选择器
• 成本：语法差异与旧浏览器编译
• 注意 & 语义与特异性变化

原生 CSS Nesting 的收益是减少父选择器重复书写、提升源码可读性与维护性，主流浏览器已原生支持。迁移成本包括：语法与 SCSS 有差异（后代选择器需显式 & 前缀，如 .card & .title 或 & .title，不能直接写 .title）；历史代码中预处理器嵌套与原生嵌套混用时语义易混淆；旧浏览器需引入 Lightning CSS 等编译工具，增加构建链复杂度；嵌套会改变最终选择器的特异性组合，需回归测试覆盖样式。建议新代码渐进采用，旧代码按模块迁移并保留构建降级。

考察原生嵌套迁移的收益与成本边界，属 CSS 工程化迁移题。回答时说明 & 语法差异与旧浏览器编译成本，强调迁移需回归特异性变化，建议新代码渐进采用。回答时给出典型示例并强调编译降级策略。

• @scope 限定样式作用范围
• donut scope 排除内部子树
• 与 Shadow DOM 的隔离强度差异

@scope 提供比命名约定更强的样式隔离：规则只在作用域根的后代内生效，donut scope 用 to() 排除特定子树，避免样式进入组件内部内容区。与 Shadow DOM 相比，@scope 不创建新的 DOM 边界，样式仍来自全局文档，依赖选择器范围而非树边界，因此隔离强度较弱但更灵活，不影响表单关联、事件冒泡等行为，也不改变样式来源。取舍：需要强封装用 Shadow DOM，需要轻量作用域控制且保持全局样式可达时用 @scope，两者也可组合。

考察 @scope 与 Shadow DOM 的隔离机制差异及选型，属组件样式隔离题。回答时对比 @scope 选择器级隔离与 Shadow DOM 树边界隔离，说明强封装选 Shadow、轻量作用域选 @scope。

• 第三方样式放入低优先级层
• 设计系统基础令牌层与组件层分离
• 业务覆盖置于未分层最高优先级

@layer 让样式按层而非特异性竞争：可将第三方库样式放入基础层，如 @layer vendor { ... }，将设计系统的 reset、tokens、components 分层放置，业务覆写放在更高层或未分层样式。由于后声明层优先、未分层样式优先于所有层，覆盖关系变得可预测，无需为第三方库追加特异性 hack 或 !important。实践中需先声明层顺序再填充内容，并约定新增样式归属哪个层，形成团队统一的样式优先级治理规范。

考察 @layer 在第三方与设计系统样式覆盖中的治理价值，属样式架构题。回答时给出第三方样式入低层、业务样式入高层的分层法，说明未分层样式优先级最高可做最终覆写。

• attr() 可读取属性字符串
• 新语法支持类型化返回值
• 旧实现只支持 content 属性

attr() 允许 CSS 读取元素 HTML 属性的值，经典用法是 content: attr(data-label)，把 data 属性渲染为伪元素文本。现代 CSS 扩展了 attr() 的类型化语法，如 attr(data-size type(), 16px) 支持长度、颜色、数字等类型并带回退值，可用于 width、background 等更多属性，不再局限于 content。限制在于浏览器实现进度不一，类型化 attr() 尚未全面普及，生产使用需特性检测；且读取的值来自 DOM 属性，动态更新属性不会自动触发样式重算，需要注意。

考察 attr() 的传统用法与类型化扩展及其兼容边界，属 CSS 函数题。注意类型化 attr() 支持度有限，回答时说明传统 content 用法与类型化语法的兼容边界及动态更新限制。

• 注册语法类型与初始值
• 使自定义属性可参与插值
• 类型校验避免非法值

@property 将自定义属性注册为带类型的 CSS 属性：声明 syntax、initial-value 与 inherits。注册后浏览器能对赋值做类型校验，非法值回退到初始值；更重要的是类型化属性可以参与 transition 与 animation 的插值，例如注册 --angle 为 后可对角度做平滑动画，实现 conic-gradient 旋转、进度环等此前需要 JS 或 hack 的效果。应用场景包括主题色渐变动画、数字滚动、旋转背景等，是自定义属性从字符串变量升级为可计算属性的关键机制。

考察 @property 的类型校验与插值能力及其应用场景，属现代 CSS 动画题。回答时给出 @property 声明 syntax/initial-value/inherits 的完整写法，说明类型校验与插值是两大收益。

• :not() 参数可包含伪类
• 链式组合表达排除多个状态
• 如 :not(:placeholder-shown):not(:user-invalid)

:not() 接受选择器列表，链式组合可精确表达排除多个状态的语义。表单校验场景中，:not(:placeholder-shown):not(:user-invalid) 表示已有输入且当前有效；:not(:user-invalid):not(:user-valid) 表示尚未验证；配合 :focus 可区分焦点状态。相比 JS 状态类，纯 CSS 表达更声明式、减少运行时逻辑。注意 :not() 的特异性取参数最高值，链式组合会累积特异性，且列表过复杂时需保持可读性，必要时拆分为多个规则。

考察 :not() 链式组合在表单状态表达中的应用与特异性注意点，属选择器应用题。回答时说明 :not() 取参数最高特异性、链式组合累积特异性，建议复杂状态拆分规则保持可读性。

• ::placeholder 选择器写法跨浏览器差异
• 占位符不能替代 label
• 对比度需满足可读性

::placeholder 样式化的注意点：旧版浏览器需 ::-webkit-input-placeholder 等厂商前缀，现代浏览器统一使用 ::placeholder；placeholder 文本默认颜色较淡，需检查与背景的对比度，确保可读。可访问性上，占位符不能替代 label，因为输入内容后占位符消失，依赖它传达字段含义会让用户与辅助技术丢失上下文；正确做法是使用可见 label 或 aria-label，placeholder 只作补充提示。工程上统一封装 placeholder 样式并遵守 label 规范。

考察 ::placeholder 的兼容写法与无障碍边界，属表单可访问性题。回答时说明占位符不能替代 label、旧浏览器需前缀，样式上保证对比度与 opacity:1 的兼容处理。

• ^= 前缀匹配语言/协议
• $= 后缀匹配文件类型
• *= 任意包含匹配灵活但易误伤

^= 适合匹配前缀，如 [lang^=zh] 匹配 zh 与 zh-CN、[href^=https] 匹配协议；$= 适合匹配后缀，如 [src$=.webp] 或 [href$=.pdf] 处理文件类型；= 匹配任意位置子串，灵活但可能误伤，如 [href=download] 可能匹配无关链接。取舍：优先用语义明确的前缀或后缀匹配，避免 *= 的宽泛匹配；国际化场景中 [lang|=zh] 专门匹配 zh 或 zh- 前缀的语言值；组合属性选择器可进一步缩小范围，但需控制选择器复杂度与可读性。

考察三类属性选择器在路径与类型匹配中的适用场景与误伤风险，属选择器应用题。回答时优先推荐语义明确的前后缀匹配，说明 *= 宽泛易误伤，国际化场景用 [lang|=zh] 精确匹配。

• 自定义属性按 DOM 树继承
• 内外层同名变量由继承就近原则决定
• 容器查询不改变级联顺序

自定义属性沿 DOM 树继承，同名变量由最近的赋值祖先决定，与是否处于 @container 内无关；@container 只是条件化应用样式的容器，不改变级联与继承规则。因此内层元素若在其祖先（包括容器根）上重新赋值 --gap，内层取值覆盖外层；若未赋值，则继承外层值。注意容器查询中变量的解析发生在规则匹配之后，变量值来自实际匹配元素的继承链，工程上可通过在容器根统一覆盖变量，让子树按容器上下文获得不同取值。

考察容器查询与自定义属性继承的交互，属级联细节题。回答时说明自定义属性按 DOM 就近继承、@container 不改变级联，可在容器根覆盖变量实现子树差异化。并说明容器根覆盖变量的实际工程做法。

• 可并行加载且利于关键 CSS
• @import 串行阻塞渲染
• @import 只能在样式表顶部

@import 会在当前样式表加载后再串行加载目标样式表，形成额外请求链并阻塞渲染，且只能写在样式表顶部； 由浏览器并行加载，配合 media、preload 等属性可精细控制加载时机，利于关键 CSS 优化。性能取舍：生产环境应避免 @import，改用 合并或构建工具内联；多个样式表合并后可减少请求数。@import 仅适合少数快速原型或分包场景。现代构建链（Vite、webpack）通常已把所有样式打包为 ，无需手工处理。

考察 @import 与 的加载语义与性能差异，属样式加载优化题。回答时说明 @import 串行阻塞、link 并行可 preload，生产环境应避免 @import 的结论。

• var() 代入 calc() 参与运算
• 变量差值实现线性缩放
• 注意 calc 运算的兼容与单位

CSS 变量可放入 calc() 参与运算，如 width: calc(var(--gap) * 2)、font-size: calc(var(--base) + var(--step))。响应式排版中常用线性插值思路：定义 --min、--max 与视口单位，font-size: clamp(var(--min), calc(var(--scale) * 1vw + var(--offset)), var(--max))，让字号随视口连续变化。组件尺寸上，把间距、圆角等参数化为变量，通过 calc() 派生组合尺寸，实现设计令牌驱动的组件体系。注意 calc() 内不同单位需可换算，且避免过多嵌套运算影响可读性。

考察 var() 与 calc() 的组合运算在响应式与组件化中的应用，属 CSS 变量应用题。回答时给出 clamp+calc+var 的线性缩放写法，说明不同单位换算与可读性控制两个注意点。

• clip 不创建滚动容器
• clip 不产生可滚动区域
• overflow-clip-margin 扩展裁切边界

overflow: hidden 会创建滚动容器，即使内容不溢出也可能通过键盘滚动或编程滚动访问到被裁切内容；overflow: clip 则强制裁切且不创建滚动容器，内容绝对不可滚动访问，语义更严格，也避免创建滚动上下文带来的布局开销。overflow-clip-margin 允许裁切边界向外扩展，例如 overflow: clip; overflow-clip-margin: 8px 让被裁内容多显示 8px，适合 box-shadow、描边等视觉溢出场景。注意 clip 不支持 overflow-x 与 overflow-y 混用。

考察 clip 与 hidden 的滚动语义差异及裁切边界扩展，属布局细节题。回答时对比 clip 不创建滚动容器与 hidden 可滚动访问的差异，说明 overflow-clip-margin 扩展裁切边界。

• min-content 取最小内容宽度
• max-content 取不换行最大宽度
• fit-content 夹在 min 与 max 之间

min-content 是元素内容在不溢出前提下能达到的最小宽度（按最长不可断词计算），适合判断最小可用空间；max-content 是内容不换行时的首选宽度，适合让元素按内容自然展开；fit-content 等价于 max(min-content, min(max-content, 可用空间))，在可用空间充足时按内容大小、不足时收缩，实现自适应。工程取舍：按钮、标签用 fit-content 避免撑满；文本块用 min-content 检测溢出风险；弹层标题用 max-content 控制宽度，配合 width 上限避免过长。

考察三种内容尺寸关键字/函数的语义与应用场景，属自适应布局题。回答时给出 min/max/fit-content 三者的定义与典型场景，说明 fit-content 在按钮与标签上的自适应价值。

• 嵌套卡片行高与父网格对齐
• 表头表体逐列对齐
• Chrome 117+/Safari 16+/Firefox 71+ 支持

嵌套卡片网格中，每个卡片内部通常再排多行内容（图片、标题、描述、操作区），若用独立 Grid，各卡片内部行高互不对齐，操作区会参差。Subgrid 让卡片内部直接复用父网格的行轨道，如 grid-template-rows: subgrid，实现跨卡片的行对齐与统一的操作区位置。浏览器支持上 Chrome 117+、Safari 16+、Firefox 71+ 均已支持 subgrid（Firefox 较早），可安全用于现代浏览器，旧浏览器可用独立 Grid 回退。实战中注意子网格需声明 grid-row 占满父轨道范围。

考察 Subgrid 在卡片对齐场景的实战用法与支持矩阵，属 Grid 进阶题。回答时说明 subgrid 需声明 grid-row 占满父轨道，给出 Chrome 117+/Safari 16+/Firefox 71+ 支持矩阵。

• inline/block 逻辑方向代替 left/right
• 自动适配 RTL 书写模式
• margin-inline-start 等映射物理边

逻辑属性使用 inline（行内方向）与 block（块方向）替代物理的 left/right/top/bottom，如 margin-inline-start 在 LTR 下等于 margin-left，在 RTL 下自动等于 margin-right。配合 direction 与 writing-mode，同一份样式在阿拉伯语等 RTL 页面中自动镜像，无需为 RTL 写覆盖规则。工程价值：减少国际化适配成本，避免漏改导致的对齐错乱。注意个别属性（如 transform 方向）仍需物理语义，过渡阶段可物理逻辑混用，但新代码应优先逻辑属性。

考察逻辑属性的方向模型及其在 RTL 布局中的自动适配价值，属国际化布局题。回答时说明逻辑属性随 direction/writing-mode 自动镜像，transform 仍物理方向，新代码优先逻辑属性。

• 断点按内容与容器设计而非设备
• viewport meta 控制布局视口宽度
• 缺少 viewport 会导致移动端缩放错乱

断点设计应基于内容与布局的自然变化点而非具体设备型号，常用 min-width 从小屏递增，配合容器查询处理组件级变化。viewport meta 如 让布局视口等于设备宽度、禁用默认缩放，是移动端响应式的前提；缺少它时移动浏览器会以 980px 布局视口渲染并整体缩放，媒体查询按错误宽度生效。二者协作：viewport 保证视口语义正确，媒体查询在正确视口上响应式切换，同时设置 maximum-scale 限制缩放会影响无障碍，需谨慎。

考察断点设计原则与 viewport meta 的协作机制，属移动端适配基础题。回答时说明断点按内容设计而非设备，viewport meta 保证媒体查询在正确视口上生效，注意缩放限制的无障碍影响。

• style() 按自定义属性值匹配
• 组件级主题响应
• 避免全局媒体查询的组件耦合

@container style(--theme: dark) 允许根据容器的自定义属性值应用样式，如容器根设置 --theme: dark 时内部组件自动切换暗色样式。相比 prefers-color-scheme 等全局媒体查询，style() 容器查询把主题决策下沉到组件容器，支持同一页面不同区域使用不同主题（如亮色正文区配暗色工具条），提升组件复用与独立演进能力。工程价值：主题令牌与容器查询结合，组件无需感知全局状态。注意 style() 查询支持度仍在完善，生产使用需特性检测与回退。

考察 style() 容器查询的组件级主题响应机制，属现代 CSS 主题化题。回答时说明 style() 查询按容器变量匹配、支持区域级主题，注意与媒体查询的适用差异与支持度。

• 旧语法 -webkit-scroll-snap-type 等前缀
• mandatory 与 proximity 的差异
• 配合 padding 与 scroll-margin 精确吸附

Scroll Snap 的兼容性陷阱：早期实现使用 -webkit-scroll-snap-type 与 -webkit-scroll-snap-points-x 等前缀语法，需保留厂商前缀兼容旧 Safari；mandatory 强制吸附可能导致内容无法停留在中间位置，proximity 更宽松但吸附不稳定，需按场景选择；吸附位置受容器 padding、子项 scroll-margin 与 scroll-padding 影响，不设置时首尾对齐偏移。规避策略：使用标准 scroll-snap-type: x mandatory 加 scroll-snap-align，同时提供前缀回退，并测试不同浏览器下的滚动体验。

考察 Scroll Snap 的兼容性与对齐细节，属轮播/画廊实现题。回答时列出旧前缀、mandatory/proximity 差异、scroll-padding 对齐三个陷阱，并给出标准加前缀的写法。

• aspect-ratio 直接声明宽高比
• auto 允许内容决定尺寸
• 替代 padding-top 百分比 hack

aspect-ratio: 16/9 直接声明元素的宽高比，配合 width 或 flex/grid 约束即可让元素按比例自适应，无需 JS 计算。相比经典的 padding-top: 56.25% 技巧，aspect-ratio 语义清晰、不受 padding/border 影响，且能结合 min/max 约束实现弹性比例。注意 aspect-ratio 在宽高都未受约束时可能不生效，需至少确定一个维度；内容溢出时可用 overflow 或 object-fit 处理。视频、封面、卡片缩略图等场景中，它让固定比例实现更简洁可靠。

考察 aspect-ratio 的声明式比例能力与传统 hack 的对比，属布局实现题。回答时说明 aspect-ratio 需至少一个维度约束，替代 padding-top hack，注意内容溢出用 object-fit 处理。

• accent-color 控制原生控件强调色
• 支持 checkbox/radio/range/progress 等
• 无法完全自定义控件内部结构

accent-color 为 checkbox、radio、range、progress 等原生控件设置强调色，一行声明即可让控件颜色与品牌主题一致，无需重写控件内部结构或引入复杂样式。它与 color-scheme 配合可在暗色模式下自动调整控件底色。限制在于 accent-color 只改变强调色，无法控制控件形状、内部图标等细节，深度定制仍需 appearance: none 自行绘制。工程上先统一 accent-color 与 color-scheme 保证基础一致性，再对关键控件做定制。

考察 accent-color 的适用范围与限制，属表单主题一致性题。回答时说明 accent-color 只改强调色，深度定制需 appearance:none，先统一基础再定制关键控件。

• from 关键字引用源颜色
• r g b 通道可做运算
• 相对颜色按通道转换，color-mix 按比例混合

相对颜色语法如 rgb(from var(--c) r g b / 0.6) 以已有颜色为源，对其通道做读取、调整与输出，可派生透明化、明度变化等变体，例如 hsl(from var(--brand) h s calc(l - 10%)) 生成暗色变体。与 color-mix 的差异：color-mix 在色彩空间内按比例混合两个颜色，适合生成中间色；相对颜色按通道变换单个颜色，适合派生同色相变体。两者都以设计 token 为输入，减少硬编码色值，让主题切换时派生色自动联动。

考察相对颜色语法的通道变换能力及其与 color-mix 的分工，属现代颜色函数题。回答时说明 from 关键字读取源颜色通道并变换，与 color-mix 按比例混合的分工，强调令牌派生一致性。

• :has() 提供父选择与关系选择能力
• 浏览器需反向匹配候选元素
• 复杂嵌套与超大列表影响性能

:has() 允许基于后代、兄弟或相对关系选择元素，解决 CSS 长期缺乏父选择器的痛点，如表单错误联动、容器状态驱动、拖拽悬停高亮等原本需要 JS 类名切换的场景。性能注意点：浏览器需要为候选元素反向遍历或维护匹配索引，:has() 参数越复杂、选择器越宽泛、DOM 规模越大，匹配开销越高；应避免在超大列表上使用多层 :has() 或与通配符、深后代组合。实践中优先用稳定、窄范围的选择器，必要时以类名替代。

考察 :has() 的能力边界与性能代价，重点是理解反向匹配机制对复杂度的放大效应。回答时先讲父选择能力解决的问题，再讲反向匹配对复杂参数与超大 DOM 的开销放大，给出窄范围选择器建议。

• 嵌套 grid 使用独立轨道
• subgrid 继承父轨道
• 跨层级对齐场景必须用 subgrid

嵌套 Grid 在子容器内部创建完全独立的轨道系统，子容器与父网格的行列尺寸互不对齐；subgrid 让子网格直接复用父网格的轨道定义与尺寸，实现跨容器逐轨道对齐。必须用 subgrid 的场景：需要把嵌套内容与父网格的行或列严格对齐，例如表格中表头与表体共享列宽、卡片网格内各卡片的行分区对齐、图表中多轴刻度对齐。若只是内部独立布局且无需对齐父网格，普通嵌套 Grid 即可，subgrid 并非必需。

考察 subgrid 与嵌套 grid 的本质差异及适用场景，属 Grid 进阶选型题。回答时以表头表体、卡片行分区为例说明必须对齐的场景，普通内部布局用嵌套 grid 即可，体现选型判断。

• @layer 按层管理优先级
• BEM 控制选择器特异性
• CSS Modules 提供命名隔离

@layer 把样式按语义分层（reset、base、components、utilities），优先级由层顺序而非选择器特异性决定，使覆盖关系可预测；BEM 通过扁平类名控制特异性，避免深层选择器；CSS Modules 通过哈希类名实现组件级命名隔离。协同方式：@layer 负责跨来源的优先级编排（如第三方库放低层、业务样式放高层），BEM 负责单文件内选择器的可读性与低特异性，CSS Modules 负责组件命名空间的隔离，三者互补，减少 !important 与深层覆盖。

考察 @layer 与既有样式方案的分工协同，属样式架构综合题。回答时按层优先级、命名隔离、低特异性三个维度说明 @layer 与 BEM/CSS Modules 的分工互补。

• box-shadow 跟随盒模型矩形
• drop-shadow 跟随元素轮廓
• 透明图标需用 drop-shadow

box-shadow 沿元素盒模型边缘绘制阴影，适合矩形卡片、按钮；对透明背景图标、异形图形，它会显示为矩形阴影，破坏视觉效果。filter: drop-shadow() 依据元素实际渲染轮廓（含透明 PNG、SVG、伪元素形状）生成阴影，能真实贴合图标形状。取舍：一般 UI 卡片用 box-shadow（性能更好、可控性强）；图标、徽标、异形元素用 drop-shadow。注意 filter 会创建层叠上下文并可能影响性能，批量图标阴影可考虑预烘焙到图片。

考察两类阴影的渲染基准差异与适用场景，属视觉实现细节题。回答时说明 box-shadow 沿盒模型、drop-shadow 沿渲染轮廓，透明图标必须用 drop-shadow 并注意 filter 开销。

• 嵌套已获主流浏览器支持
• Anchor Positioning 支持仍在完善
• 用 @supports 与基础样式降级

CSS Nesting 已被 Chrome、Safari、Firefox 主流版本原生支持，属稳定可用能力；Anchor Positioning 的支持仍在推进，Chrome 125+ 可用，Safari 与 Firefox 正在实现中。降级策略：嵌套可通过构建工具（Lightning CSS）编译为扁平选择器兼容旧浏览器；Anchor Positioning 则先提供不依赖锚点的默认定位（如 static 或固定位置），再用 @supports (anchor-name: --x) 或 @supports (position-area: top) 渐进增强，并保留 JS 测量定位作为兜底，确保不支持浏览器功能可用。

考察两项新特性的支持现状与渐进增强降级策略，属现代 CSS 兼容性题。回答时区分 Nesting 已主流支持与 Anchor 仍在完善，给出 @supports 渐进增强与 JS 兜底的双层降级。

• HSL 亮度不感知均匀
• OKLCH 的 L 接近感知亮度
• 保证色阶与插值视觉一致

HSL 的 L（明度）与 S（饱和度）基于 sRGB 数学转换，与人的感知不一致：不同色相下相同 L 视觉明暗差异大，纯黄与纯蓝在相同 L 下亮度差异明显，导致色阶生成与插值出现灰暗带。OKLCH 的 L 通道接近人眼感知亮度，C、H 通道也经过感知校正，相同数值步长视觉等距。设计系统价值：用 OKLCH 生成的色阶明度一致、渐变插值不偏灰、跨色相配色稳定，适合做色彩令牌与主题变体，配合 culori 等工具可程序化生成。

考察 OKLCH 与 HSL 的感知差异及其设计系统价值，属色彩管理题。回答时以同 L 不同色相明暗差异说明 HSL 不感知均匀，OKLCH 适合色阶与插值，配合工具程序化生成。

• prefers-contrast: more 增强对比
• 调整文字、边框与背景
• forced-colors 是更强的强制模式

prefers-contrast: more 表示用户偏好更高对比度，前端可据此加深文字颜色、增强边框、提高背景与前景的对比度；prefers-contrast: less 表示偏好低对比度。与 forced-colors 的区别：forced-colors 激活时系统强制替换作者颜色、主要靠系统色关键字适配；prefers-contrast 只是表达偏好，作者颜色仍然生效，可以精细微调。工程实现：先保证默认样式满足 WCAG AA，再用 prefers-contrast 叠加增强（如加深描边、去透明），并确保不与暗色模式逻辑冲突。

考察 prefers-contrast 的语义与 forced-colors 的差异，属无障碍适配题。回答时说明 prefers-contrast 表达偏好且作者颜色生效，forced-colors 强制替换，二者适配策略不同。

• 变量更新触发样式重算
• 批量更新减少重算次数
• transform/opacity 层动画不受影响

修改 CSS 自定义属性会改变依赖它的属性取值，浏览器需重新计算样式（style recalc），若依赖属性涉及布局（宽度、边距），还会触发重排。性能影响与依赖变量元素的数量成正比。优化：在 :root 或高层容器上一次批量更新多个变量，减少多次写入引发的重复重算；避免把频繁变化的变量用于 layout 属性，主题色等用于 color/background 时通常只触发绘制；动画尽量使用 transform/opacity 走合成层；必要时用 requestAnimationFrame 合并更新。

考察自定义属性主题切换的重算成本与优化手段，属性能优化题。回答时说明变量更新触发样式重算，批量更新与避免 layout 属性可减少开销，动画优先 transform/opacity。

• 的 media 属性匹配系统偏好
• source 提供暗色/亮色图片
• 无匹配时回退 img

使用 元素配合 source 的 media 属性可以根据系统偏好加载不同图片： 内第一个 source 的 media="(prefers-color-scheme: dark)" 在暗色模式时使用暗色图片，再放一个 source 用于亮色，最后的 作为回退。浏览器会选择第一个匹配的 source，从而实现不引入 JS 的图片替换。注意要正确设置 srcset/sizes 与 alt 文本，暗色图片也要检查对比度与可读性，且缓存策略需考虑两套资源的体积。

考察 picture 元素按偏好加载图片的实现方式，属响应式图片与主题结合题。回答时给出 picture+source media 的完整结构，说明 img 回退与 alt 文本、两套资源体积的注意点。

• 普通文本要求 4.5:1，大文本 3:1
• 在 CI 中运行对比度检查
• 令牌配对校验与生成报告

WCAG 2.x 要求普通文本与背景的对比度至少 4.5:1，大号文本（约 24px 以上或 18.66px 加粗）为 3:1，UI 组件与图形也有 3:1 要求。设计系统自动化校验思路：维护色彩令牌与前景/背景配对关系，在 CI 中用 axe-core、pa11y 或自写脚本基于 WCAG 相对亮度公式计算对比度，不达标即失败并输出报告；也可在开发期用 stylelint 插件或 Figma 插件校验。实现时注意 alpha 透明度需先与背景合成再计算，并覆盖暗色主题的配对。

考察对比度标准与自动化校验的工程实现，属设计系统可访问性题。回答时说明 4.5:1 与 3:1 的适用对象，CI 中按相对亮度公式自动校验令牌配对，注意透明度合成。并给出 CI 失败即阻断的落地方式。

• @color-profile 注册 ICC 配置文件
• 支持自定义色彩配置文件
• 浏览器支持有限需谨慎

@color-profile 允许在 CSS 中引入自定义 ICC 颜色配置文件，并通过 color() 函数使用配置空间中的颜色，适合需要精确匹配品牌印刷色、专色等场景。当前浏览器支持有限，仅 Chrome 等部分浏览器实现，且配置文件的加载与解析增加复杂度。工程取舍：优先使用浏览器广泛支持的广色域方案（display-p3 等），@color-profile 用于对色彩精确度要求极高且目标浏览器可控的场景，并提供 sRGB 回退；生产前需做支持检测与视觉回归。

考察 @color-profile 的用途与支持现状，属高级色彩工程题。回答时说明 @color-profile 引入 ICC 配置支持有限，优先 display-p3，必要时 sRGB 回退。

• mix-blend-mode 混合元素与底层
• background-blend-mode 混合层内背景
• 混合模式影响对比度与文本可读性

mix-blend-mode 将元素与其下层内容混合（如文字与图片），background-blend-mode 只混合元素自身的多层背景。视觉叠加场景常用 multiply、overlay 等模式制造质感。可访问性冲突：混合模式可能大幅改变文字与背景的实际对比度，导致文本难以阅读；文字与图片的混合会让颜色随底层变化，难以满足 WCAG 对比度要求。工程建议：正文文字避免使用混合模式，或提供无混合的降级样式；用自动化对比度检查覆盖混合场景；必要时对混合区域单独设置高对比回退。

考察两类混合模式的区别及其对可读性/对比度的冲突，属视觉与无障碍交叉题。回答时区分 mix-blend 与 background-blend 作用范围，说明混合破坏对比度时需无混合降级样式。

• 类型化颜色校验
• 支持颜色插值动画
• 主题变体自动派生

用 @property 把调色板变量注册为 类型，可获得类型校验：赋值非法颜色时回退初始值，避免脏数据污染样式；更重要的是类型化颜色可参与 transition 与 animation 插值，实现主题色平滑过渡、hover 颜色渐变等效果。工程优势还体现在变量可作为相对颜色与 color-mix 的可靠输入，派生变体一致；配合设计令牌，调色板升级时无需改动使用方。注意 @property 需在样式表顶层声明，且注册后同名变量语义统一，团队约定可避免重复注册冲突。

考察 @property 注册调色板的类型校验与插值优势，属现代 CSS 工程题。回答时说明 @property 注册调色板获得类型校验与插值能力，注意顶层注册与同名变量语义统一。

• :root[data-theme] 作为主题开关
• data-theme 覆盖变量集
• 默认跟随系统偏好

:root[data-theme="dark"] 等选择器通过切换 html 元素的 data-theme 属性，应用不同主题变量集，是最常见的运行时主题机制：CSS 中为每个主题定义变量覆盖，JS 或内联脚本切换属性即可全局换肤。与系统偏好的协作：默认不设置 data-theme 时，用 @media (prefers-color-scheme: dark) 下的变量覆盖跟随系统；用户显式选择后，data-theme 的优先级高于媒体查询，实现三态（跟随系统、强制亮、强制暗）。注意变量继承使切换只需改根节点，配合 localStorage 持久化选择。

考察 data-theme 主题机制与系统偏好的优先级协作，属主题化综合题。回答时说明三态优先级：默认跟随系统、data-theme 显式覆盖、localStorage 持久化，避免首屏闪烁。

• lab/lch 感知均匀
• oklab 修正 lab 的蓝紫问题
• 动画插值不偏灰

lab() 与 lch() 是感知均匀色彩空间，插值结果比 sRGB 空间更符合人眼，减少中间色偏灰；oklab() 在 lab 基础上进一步修正蓝紫色感知失真，是更现代的选择。工程价值体现在颜色过渡与动画：在两个主题色或状态色之间 transition，浏览器在插值时若使用感知空间（如 color-mix(in oklab) 或注册为 oklab 类型变量），中间帧视觉更平滑自然。注意默认插值空间由颜色函数决定，如需感知插值可显式在 oklab/oklch 中定义颜色，兼容性上需提供回退。

考察感知色彩空间在颜色动画插值中的价值，属现代色彩动画题。回答时说明 oklab 修正蓝紫失真，插值空间由颜色函数决定，显式用感知空间定义可提升过渡质量。回答时结合动画过渡示例说明更佳。

• hue-rotate 旋转色相
• 可增强红绿色弱对比
• 滤镜无法完全补偿且影响性能

filter: hue-rotate() 可整体旋转元素色相，某些色弱场景下通过调整色相映射，让原本难以区分的颜色产生可辨识差异，例如为红绿色弱用户提供色相偏移滤镜选项。工程实现：提供辅助模式开关，对页面主内容应用滤镜；同时结合 CSS 变量与 SVG 滤镜（feColorMatrix）定制更精确的颜色映射。限制：hue-rotate 对全页统一旋转会扭曲正常颜色与品牌色，且滤镜覆盖整个页面有性能开销；更优方案是设计系统层面提供高对比、色弱友好的配色令牌，而非依赖全局滤镜。

考察色弱辅助的实现手段与全局滤镜的局限，属无障碍与视觉交叉题。回答时说明 hue-rotate 全局色相扭曲与性能开销，更优方案是令牌级色弱配色而非全局滤镜。回答时说明辅助开关与性能权衡两点。