兼容性治理

• 三类数据源的时效性与权威性差异
• 一手证据（引擎实现状态、官方发行说明）优先于二手聚合数据
• 从"声称支持"到"实测验证"的证据链

Can I Use 是社区维护的聚合数据、MDN BCD 是规范的兼容性数据库，二者都依赖人工与自动化收集，存在滞后、错误与争议条目；浏览器官方发行说明、ChromeStatus、Firefox Platform Status 属于一手来源。冲突时应按证据链裁决：先查引擎实现状态页与官方发行说明（含实验标志要求），再看 MDN BCD 的版本数据、规范链接与相关 issue，最后参考 Can I Use 的 status 与 usage 字段；仍存疑时以真实浏览器实测为准，并记录测试环境、日期与版本号。核心是区分"声称支持"（数据条目）与"实测可用"（真实运行），任何聚合工具都只能作为索引而非结论。

考察对前端兼容性证据体系的分级认知：官方一手数据（引擎状态、发行说明）优先于聚合数据（Can I Use、BCD），冲突时按"实现状态—规范数据—社区数据—本地实测"的顺序裁决，并强调可复现的实测记录。

• 每行数据附带采集日期与浏览器版本快照
• 功能标志与部分支持的细分记录
• 缺陷链接与"决策依据"字段的可追溯性

可追溯的兼容矩阵每行至少包含：特性名称、浏览器与版本范围、支持状态（支持/部分支持/不支持）、功能标志及其默认值、验证日期与验证人、关联缺陷链接（bug 或 issue 编号）以及"当时为何如此决策"的依据字段。版本更新后要重现历史决策，必须做到"只追加不覆盖"：新数据写入新行并保留 changelog，矩阵文件纳入版本管理，历史快照可随时检出。部分支持要细分到子特性或带条件描述（如"仅带 -webkit- 前缀可用"），不能折叠为"支持"。

考察兼容数据治理的工程细节：矩阵本质是可审计的决策记录，需包含版本快照、验证日期、缺陷引用与决策理由，更新时保留历史，才能支撑跨版本重现历史决策。

• Masonry 按行/列方向填充对视觉顺序的影响
• 视觉重排导致键盘 Tab 顺序错位的风险
• 顺序一致性校验与修复策略

Masonry（grid-template-rows: masonry 等实验语法）按"先列后行"或"先行后列"方向填充，会改变内容的视觉呈现顺序；键盘焦点按 DOM 顺序移动，若视觉顺序与 DOM 顺序不一致，用户 Tab 遍历时焦点会在屏幕上跳来跳去，破坏可访问性。保持一致的原则是：优先让 DOM 顺序即视觉顺序——采用逐项顺序填充且不跨方向重排；确需重排时评估是否可接受，或用 grid-lanes 提供的顺序保持机制；上线前用自动化脚本对比"视觉位置排序"与"DOM 顺序"，并做键盘导航实测，防止顺序错位进入产物。

考察 CSS 新布局与可访问性的交叉点：任何视觉重排（masonry、grid/flex 的 order、多列）都可能割裂视觉顺序与 Tab 顺序，答案需给出"保持 DOM 顺序优先、重排需评估、上线前自动化校验"的完整策略。

• 锚点失效的典型场景（裁剪、滚动出视口、containing block 移出）
• position-visibility: anchors-visible 的隐藏语义
• @position-try 回退位置与浮层稳定性

锚点定位的浮层依赖锚链（anchor chain），当锚点被 overflow 裁剪、滚动出视口或移出 containing block 时，定位基准失效，浮层会悬空或跳变。position-visibility: anchors-visible 让浮层在锚点不可见时自动"不可见"（不渲染但不中断布局），配合 @position-try 定义的 try-fallbacks 按优先级尝试替代位置（如吸附视口边缘），即可避免突兀跳变。工程上还需注意：overflow: clip/hidden 的裁剪容器会截断锚链，浮层回退策略要包含"隐藏并保证触发元素焦点可达"，并在真实滚动容器中做视觉回归验证。

考察 Anchor Positioning 的工程边界：浮层稳定性取决于锚点可见性与 containing block 裁剪，position-visibility 提供隐藏语义、@position-try 提供位置回退，二者组合才能避免跳变。

• @layer、@scope 与 Shadow DOM 的层叠叠加关系
• 继承与自定义属性跨 shadow 边界的传播规则
• ::slotted() 的样式来源与层叠位置

三者叠加时按"先分层、再比接近度、后看特异度"裁决：Cascade Layers 按声明顺序给规则分层，@scope 在同一层内按作用域接近度细化胜出规则，Shadow DOM 则形成宿主上下文与 shadow 树之间的样式边界。继承沿 DOM 树传播，自定义属性作为继承属性可以穿越 shadow 边界，但普通类选择器规则不会穿透；::slotted() 是 shadow 树内为 slot 内容提供样式的入口，其声明属于 shadow 树内样式表，参与 shadow 内部的层叠，与外部规则的竞争发生在宿主层级。关键区分：跨边界时生效的是"继承值"而非"外部规则"，边界内才适用选择器级层叠。

考察对级联体系分层的理解：@layer 管优先级分层、@scope 管作用域接近度、Shadow DOM 管样式边界，继承与自定义属性按继承语义跨边界传播，::slotted() 属于 shadow 内部层叠。

• 引擎差异的具体行为表现（CSS 解析容错、前缀遗留、滚动条、微任务时序、Intl 数据）
• 同引擎多品牌（Chrome/Edge/Opera）与换引擎品牌（旧 Edge）的识别
• 按"引擎→版本→品牌"组织矩阵

差异体现在具体行为上：CSS 解析容错不同（非法属性值、未知语法的忽略策略），-webkit- 前缀遗留导致部分属性行为不一致；滚动条样式（WebKit 的 ::-webkit-scrollbar 高度定制 vs Firefox 的 scrollbar-width/scrollbar-color）与弹性滚动（momentum scrolling、overscroll 行为）各异；Promise 微任务时序在 V8、SpiderMonkey、JavaScriptCore 的作业调度细节上存在差异，影响依赖时序的框架行为；Intl 区域数据因引擎内置 ICU/CLDR 版本不同，同一 locale 的日期、数字格式化结果不同。兼容矩阵应按引擎维度组织：先列引擎（Blink/Gecko/WebKit）与引擎版本，再映射品牌（Chrome 与 Edge 共享 Blink 但功能开关可能不同），避免把"Chrome 18 与旧 Edge 18"当成同一行为。

考察"引擎与品牌分离"的认知：同一品牌可能换引擎（旧 Edge→Chromium），同一引擎支撑多个品牌，兼容矩阵按引擎版本组织才能抓住行为差异根源。

• 自愿填写（opt-in）抽样的自选择偏差
• 受访者结构漂移与题目变化的纵向可比性问题
• 把调查当趋势信号而非采用率证据

这类调查采用自愿填写制，样本自选择严重：参与者多为活跃社区开发者，偏向英语地区与特定渠道，不能代表全体开发者或真实用户。跨年度比较时，受访者结构变化（社区热度迁移、引流渠道变化）、题目增删改（新增选项、调整措辞、分组变化）都会改变应答分布，直接比较两年百分比会产生误导。正确解读：只看"注意力的相对变化方向"而非绝对值，比较时检查样本量与过滤条件（如是否排除"没听说过"），并明确结论只适用于该样本人群；绝不能以调查流行度替代浏览器遥测作为兼容性证据。

考察对调查数据方法论的批判性理解：自选择偏差、受访者漂移、题目变化共同削弱纵向可比性，答案需说明"方向信号 vs 数值结论"的区分与证据边界。

• Can I Use JSON 数据结构（feature/stats/usage/notes）的映射
• y/n/a/x 状态矩阵与使用率加权
• 数据快照、生成时间与变更记录的可审计性

转换步骤：从 caniuse 数据包读取 feature 的 status（rec/wd/other）、stats（各浏览器各版本的支持状态 y/n/a/x）、usage_perc 与 notes，输出结构化兼容表，每行包含：特性名、浏览器、最低支持版本、状态（完整支持/前缀/部分/不支持）、加权使用率（可叠加区域维度）与备注链接。可审计性要求：锁定 caniuse 数据快照版本（package-lock 或 vendoring）、记录生成工具与时间、表格纳入版本管理并保留 changelog，CI 定期重跑更新快照。a（部分支持）与 x（带前缀）状态必须展开为条件说明，禁止折叠成"支持"。

考察把聚合数据工程化的能力：定义 feature→browser→version 的结构化映射、正确处理 y/n/a/x 矩阵与使用率加权、固化快照与生成流水线，使兼容表可追溯、可重算。

• Baseline 的定义：核心浏览器集与 30 个月窗口
• 三种状态与最低支持版本矩阵的对应关系
• 用 Baseline 简化目标但保留完整矩阵兜底

Baseline 以 Chrome、Edge、Firefox、Safari 四个核心浏览器为集合：特性在这四者全部支持时进入 Newly Available（以最后一个支持浏览器的版本与日期为起点），经过 30 个月后进入 Widely Available；非 Baseline 表示至少一个核心浏览器尚未支持。映射到版本矩阵：Newly Available 对应"记录四个浏览器各自的最低支持版本"；Widely Available 在版本矩阵上叠加"30 个月窗口"标记；非 Baseline 条目保留完整矩阵并标注缺口浏览器。工程上可用 Widely Available 作为默认底线、Newly Available 要求降级，但非 Baseline 特性仍需完整矩阵与回退方案。

考察对 Baseline 语义的准确理解：Baseline 把"四浏览器全支持+时间窗口"抽象为两档状态，映射矩阵时需保留最低版本信息，不能以状态标签替代完整矩阵。

• 两种数据的度量对象与来源差异
• 各自适合回答的问题（生态趋势 vs 兼容风险）
• 组合使用的正确姿势

开发者调查度量的是"开发者的兴趣与采纳意愿"，样本来自自愿填写的社区开发者，存在自选择与渠道偏差；浏览器遥测（RUM、GA、自有埋点）度量"真实用户实际使用的浏览器与版本分布"，是兼容性决策的直接证据。二者必须分开解读：调查数据回答"生态往哪个方向走、值不值得学"；遥测回答"我的用户能否用、要不要降级"。具体做法：兼容性裁决以遥测覆盖率为准（如某能力在目标流量中覆盖率不足 95% 则必须降级），调查只作为技术选型的前瞻信号；同时为调查结论标注样本边界，避免把流行度包装成兼容性证据。

考察数据驱动的技术决策：两类数据服务不同问题，答案应明确"流行度（survey）与覆盖度（telemetry）"的边界，并以遥测作为兼容性裁决依据。

• (root) 与 to (upper limit) 定义的作用域边界
• donut scope 的排除语义
• 级联接近度作为新增胜出维度及其与特异度的裁决顺序

@scope (root) 限定作用域根，to (upper) 限定作用域上限，形成树状边界；donut scope 指作用域中间存在不应用样式的子树，用于在组件内部精确排除局部区域。胜出规则的关键变化是级联接近度（cascade proximity）：当两条规则同层且都命中元素时，DOM 树距离更近的 @scope 规则优先，即使其选择器特异度更低；比较顺序为"先分层（@layer）→ 再比接近度 → 后比特异度"。工程上 @scope 让组件样式就近覆盖、减少特异性 hack，但需注意与 @layer 的叠加裁决，并控制作用域边界的可维护性。

考察对 CSS 级联新维度的理解：@scope 引入接近度维度并与特异度、层叠层组合裁决，donut scope 提供精确排除边界，回答需给出完整裁决顺序。

• 容器查询的祖先依赖链与循环依赖风险
• 尺寸查询、style() 样式查询与 scroll-state 查询的组合约束
• 稳定查询策略与默认值兜底

容器查询基于祖先容器尺寸，嵌套场景中后代布局变化可能反向影响祖先尺寸，形成"查询→布局→再查询"的循环。规避方法：容器查询只读取祖先容器、不反向改变其尺寸（避免容器尺寸依赖自身内容）；优先查询稳定的容器（固定宽度 wrapper），样式查询用 style() 查自定义属性而非依赖布局结果；scroll-state 查询只读滚动位置，不应与尺寸查询互相触发。工程上限制查询嵌套深度、把状态用类名或自定义属性外置同步，并为每个查询设置不成立时的默认值，保证布局可预测。

考察容器查询体系的工程约束：循环依赖来自"查询依赖的尺寸/状态被查询结果改变"，答案需给出单向依赖、稳定容器、状态外置与默认值兜底等规则。

• 按真实用户流量占比而非浏览器数量加权
• LTS、WebView 与系统浏览器的更新节奏差异
• 权重表定期重算与例外审批机制

兼容权重应基于各运行环境承载的真实用户流量占比计算，而不是按浏览器种类均分。三类环境差异显著：长期支持版（LTS/ESR）版本滞后、WebView 的更新依赖宿主应用与系统（Android System WebView 受设备与商店分发影响）、移动端系统浏览器（Safari 绑定 OS、老 Android 浏览器碎片化）更新不可控。计算步骤：从遥测按"浏览器+版本+运行环境"分桶统计 UV 占比，对每个能力计算"目标流量内的可用覆盖率"，低于阈值（如 95%）即要求降级或 polyfill；LTS 与 WebView 桶单独标注滞后风险，权重表定期重算并保留例外审批流程。

考察企业级兼容治理：权重本质是流量加权覆盖率，需区分各类环境的更新节奏风险，并建立定期重算与例外审批机制。

• browserslist 作为统一目标矩阵与转译/前缀生成
• eslint-plugin-compat 与 Can I Use 数据快照的静态拦截
• Baseline 目标门禁与例外审批

三层防线：构建期用 browserslist 定义目标矩阵，Babel/PostCSS 按同一矩阵转译语法并自动加前缀（autoprefixer）；静态检查期用 eslint-plugin-compat 对照 Can I Use 数据快照检测 API 使用，未达标即报错；门禁期以 Baseline（Widely Available）为默认底线，对非 Baseline API 的使用按 warn/error 分级，允许携带降级方案的例外。关键实践：锁定 Can I Use/BCD 数据快照版本、browserslist 变更走评审、把语法转译、API lint、前缀生成三类检查纳入同一矩阵，确保不支持的语法或 API 无法进入产物。

考察 CI 兼容门禁的完整链路：browserslist 是统一矩阵源头，转译、lint、门禁三层分别拦截语法、API 与策略问题，答案需强调快照锁定与例外流程。

• 地区与语言分布对结论适用范围的影响
• 社区渠道带来的样本偏差
• 幸存者偏差造成的高估与沉默样本缺失

典型误判包括：把"英语为主、欧美开发者占多数的受访者偏好"当成全球共识；把特定渠道（如 Twitter/X 前端圈）的热度当成普遍趋势；幸存者偏差——对新技术感兴趣且已投入的开发者更愿意填写，导致"使用率"被系统性高估，而体验后放弃的沉默样本缺失；低版本、低能力环境的开发者少发声，造成"现代 Web 能力已普及"的错觉。正确做法：阅读报告时关注样本量、地区与语言占比、筛选条件，把结论限定在样本代表的人群，并对关键判断用其他数据源交叉验证。

考察调查方法学的批判性应用：地域、语言、渠道决定样本代表性，幸存者偏差决定方向性乐观，答案需说明误判形态与交叉验证策略。

• 六种容器查询单位的含义与"最近合格祖先"规则
• 无合格容器时回退为小视口单位的语义
• 回退行为的隐性风险与排查方法

cqw/cqh 是查询容器宽/高的 1%，cqi/cqb 是内联/块向尺寸的 1%，cqmin/cqmax 取两者中的较小/较大值。回退规则：元素向上查找最近的合格查询容器（声明 container-type 且 container-name 匹配的祖先）；找不到合格容器时，这些单位回退为对应的小视口单位（svw/svh 等），行为退化为视口基准而不会报错。这既是便利也是风险：忘记设置 container-type 时布局会悄悄改用视口尺寸，表现为"看起来奇怪"；工程上应显式设置容器，使用容器查询单位时确认祖先容器存在，并在调试时检查计算值。

考察容器查询单位的精确语义：六种单位对应容器尺寸的不同切面，无容器时回退为小视口单位是关键边界，答案需指出隐性风险与排查方法。

• @supports 特性检测与浏览器矩阵核对
• grid 自动密度与多列布局回退方案的顺序影响
• 回退路径上的焦点顺序一致性验证

步骤：先用 @supports (grid-template-rows: masonry) 或 (masonry: auto) 检测原生支持，并对照浏览器矩阵确认目标环境覆盖范围；不支持时回退到"视觉顺序=DOM 顺序"的方案：普通 grid（固定列数、自动行高）、CSS columns 多列或 JS 瀑布流。关键约束：回退不得改变 DOM 顺序，以免破坏键盘 Tab 顺序与屏幕阅读器顺序；CSS columns 按列填充天然改变阅读顺序，若不可接受应改用 grid 显式放置或 JS 计算实现，并在回退路径上自动验证焦点顺序与视觉顺序一致性。

考察新布局的渐进增强实施：@supports 检测加矩阵确认加顺序安全回退是标准套路，难点在 columns 按列填充的顺序陷阱，答案应对比各回退方案的顺序影响。

• 视觉回归层覆盖缩放、竖排与 RTL 快照
• 逻辑属性断言与 dir/writing-mode 切换测试
• 键盘遍历模拟与 axe-core 扫描组合

自动化验证分四层：视觉回归层用 Playwright 多视口截图对比，覆盖 200% 缩放、竖排文字（writing-mode: vertical-rl）与 RTL（dir=rtl）快照；结构层断言使用逻辑属性（inset-inline、margin-inline 等）而非物理属性，并可自动切换 dir 重跑布局测试；交互层用键盘事件模拟 Tab/Shift+Tab 遍历，断言焦点顺序、可见性与 focus-visible 状态；可访问性层接入 axe-core 自动扫描 ARIA、对比度与标签，在 CI 中作为门禁，同时保留屏幕阅读器人工抽查。关键是把"缩放/RTL/竖排/键盘"做成可重复的测试矩阵，避免上线后回归。

考察布局上线的质量门禁：自动化要覆盖环境切换（缩放、方向、书写模式）与交互顺序两个维度，axe-core 覆盖静态语义、键盘模拟覆盖动态顺序，二者互补。