浏览器与平台演进

共 17 题

#

1. Chrome Built-in AI（Prompt API）的客户端模型集成，Gemini Nano 在 Web 应用的部署与隐私优势？

A Prompt API 让 Gemini Nano 在客户端本地推理，数据不出设备、免 API 费用，应用需能力检测并按任务轻重与云端模型分层 ✓ 正确答案

B 所有 Chrome 版本默认内置已下载好的模型

C Gemini Nano 的推理必须在服务端完成

D Built-in AI 不支持流式输出

#

2. Web Platform Baseline 标准对团队浏览器支持策略的影响，如何用它做特性决策？

A Baseline 只统计 Chrome 的支持情况

B Limited availability 的特性可以直接无脑使用

C 进入 Baseline 的特性在所有浏览器行为完全一致

D Baseline 以两条主流浏览器链支持为进入门槛，团队按 Newly/Widely 阶段匹配支持矩阵，再结合降级成本与灰度发布做特性决策 ✓ 正确答案

#

3. Popover API、Anchor Positioning、Interest Invoker 等 新原生 UI API 对组件库的替代

A Interest Invoker 用于服务端渲染的请求合并

B 原生 Popover/Anchor Positioning 无法实现任何浮层

C 使用原生 API 后组件库将完全失去作用

D Popover API 提供原生顶层浮层与交互管理，CSS Anchor Positioning 提供锚定定位，标准浮层可直接原生实现，复杂场景组件库改为封装这些原生能力 ✓ 正确答案

#

4. 浏览器内置 AI（Chrome Built-in AI/WebNN）与第三方大模型 API 的选型边界（隐私/离线/成本）？

A 第三方 API 在隐私与离线场景总是更优

B 内置 AI 的模型能力与云端大模型完全一致

C 内置 AI/WebNN 本地推理在隐私、离线与免费用上有优势但能力有限，宜按"本地轻任务、云端重任务"分层混合并统一抽象 ✓ 正确答案

D WebNN 只能用于训练模型

#

5. 值得跟进的新 Web API（如 View Transitions、Navigation API、OPFS）如何评估其工程价值？

A 新 API 只要进入 Chrome 就可以全面采用

B 评估只需关注 API 的性能指标

C 从成熟度、收益、替代成本与降级风险四维评估，走特性检测 + 低风险试点 + 保留回退预案的渐进路径 ✓ 正确答案

D 采用新 API 后无需考虑旧浏览器

#

6. 浏览器的 Web Platform 新特性，基线（Baseline）演进？

A Baseline 状态由各浏览器厂商单独发布，无统一口径

B MDN 的 Baseline 徽标反映的是该特性在服务端的状态

C 特性经双浏览器链支持进入 Newly available，30 个月后转 Widely available，团队应将其状态纳入支持矩阵规范并跟踪 Origin Trial 的登记与退出 ✓ 正确答案

D 进入 Baseline 后特性永不变化

#

7. 浏览器平台的新 API，文件系统、剪贴板、多屏？

A 多屏 API 只能在 PWA 中使用

B 剪贴板读取不需要任何用户授权

C OPFS 在所有浏览器中 API 完全一致

D File System Access（含 OPFS）、ClipboardItem 与 Window Management 各提供新能力，均需能力检测与用户授权，并保留无 API 时的降级路径 ✓ 正确答案

相关文章： OPFS、多屏与设备接口的浏览器平台能力 API

#

8. CSS 新特性对前端工程的影响，@scope、text-wrap、scroll-driven animations 与 masonry 的落地现状？

A masonry 已进入 Widely available，可直接使用

B scroll-driven animations 所有浏览器都已支持

C @scope 与 text-wrap 已较广泛可用，scroll-driven animations 在 Chromium 与 Safari 26+ 可用但 Firefox 尚未支持，masonry 仍处实验阶段，应按支持度分批采用与降级 ✓ 正确答案

D @scope 与 BEM 完全冲突，二者不可共存

相关文章： @scope、Container Queries 与 :has() 的 CSS 新特性落地

#

9. Container Queries 与 :has() 选择器的成熟应用与项目级规范

A Container Queries 与媒体查询完全等价

B :has() 只能选择子元素，无法选择兄弟元素

C 容器查询让组件按容器宽度自适应、:has() 实现父选子状态样式，项目上需限定容器职责与命名、注意 :has() 选择器性能并与媒体查询分层 ✓ 正确答案

D container-type: inline-size 会破坏布局

相关文章： @scope、Container Queries 与 :has() 的 CSS 新特性落地

#

10. 跨浏览器差异（Safari/Chrome/Firefox）的治理，特性检测、polyfill 策略与灰度发布？

A 通过 UA 嗅探即可可靠判断浏览器能力

B 用能力检测（含 @supports）决定分支、按收益选择 polyfill 并对布局类特性优先降级、最后用灰度发布与 RUM 监控兜底 ✓ 正确答案

C polyfill 应该全量加载以保证一致性

D 灰度发布无法用于前端特性

#

11. 浏览器引擎的差异，Chromium/Safari/Firefox 的兼容策略？

A 按用户占比分级支持、用 Playwright 跨引擎测试矩阵锁定回归、按 Baseline 分级采用特性并用 RUM 监控引擎特异问题 ✓ 正确答案

B 三大引擎对新特性的支持速度完全一致

C 兼容策略就是全部使用 polyfill

D Safari 与 Chrome 的渲染行为保证一致

#

12. Web 标准的参与，提案到 Baseline 的流程？

A 提案一旦提交就不会被修改

B 普通工程师无法影响标准演进

C Baseline 是规范草案的别称

D 特性经提案、草案、试用反馈与推荐等阶段演进，双浏览器链实现并稳定后才进入 Baseline，工程师可通过 Origin Trial 反馈与 wpt 测试参与 ✓ 正确答案

#

13. 平台能力扩张，文件系统、蓝牙、串口等 Web API？

A 设备与文件类 API 多由 Chromium 系先行且要求安全上下文与用户手势授权，采用需评估场景匹配、权限降级与跨浏览器缺失的影响 ✓ 正确答案

B 这类 API 无需用户授权即可访问

C 这些 API 在所有浏览器中均已稳定可用

D 串口 API 在 Firefox 中支持最完善

相关文章： OPFS、多屏与设备接口的浏览器平台能力 API

#

14. WebGPU 与图形平台演进？

A WebGPU 是 WebGL 2 的简单升级版

B WebGPU 是面向现代 GPU 的渲染与计算 API，支持 Compute Shader，Chromium 与 Safari 26+ 已支持，工程上以封装渲染器并提供 WebGL 回退的方式渐进采用 ✓ 正确答案

C WebGPU 只能在 Safari 中使用

D WebGPU 不支持计算着色器

相关文章： OPFS、多屏与设备接口的浏览器平台能力 API

#

15. 浏览器安全模型演进，第三方 Cookie 移除？

A 第三方 Cookie 将在所有浏览器一次性全部禁用

B Chrome 渐进淘汰第三方 Cookie，替代方案按场景区分（FedCM 认证、CHIPS 分区、Attribution 归因），工程上按盘点、迁移、监控三步应对 ✓ 正确答案

C 第三方 Cookie 移除不影响登录与埋点

D 替代方案只有一种统一 API

#

16. 浏览器发布节奏（Chrome 4 周/6 周周期、Safari/Firefox 更新）与 Baseline 对特性采用与 polyfill 策略的影响？

A Chromium/Firefox 4 周发布而 Safari 随系统升级、普及偏慢，特性采用与 polyfill 维护周期应按用户实际的引擎分布与最慢升级节奏规划 ✓ 正确答案

B 所有浏览器都按相同的发布周期更新

C Safari 用户总能即时获得新特性

D Baseline 与浏览器发布节奏无关

#

17. CSS Anchor Positioning（CSS-Tools Level 4）的 tooltip/popover 零 JS 实现

A 锚点定位必须用 JS 计算偏移量

B anchor-name/position-anchor 声明绑定、position-area 定位、position-try-fallbacks 自动避让，配合 Popover API 可实现零 JS 的 tooltip/popover ✓ 正确答案

C position-try-fallbacks 用于定义动画曲线

D 所有浏览器都已完整支持该特性