浏览器与平台演进

• Prompt API（window.ai / LanguageModel）的调用形态
• Gemini Nano 本地推理的部署模式（下载、会话、能力检测）
• 隐私与成本优势（数据不出设备、无 API 费用）

Chrome Built-in AI 把 Gemini Nano 模型内置进浏览器，通过 Prompt API（window.ai.createTextSession / LanguageModel 接口）在客户端直接执行文本生成，无需服务端转发。部署模式：首次使用按需下载模型（浏览器管理下载与更新），应用通过能力检测（window.ai 是否存在）决定启用或降级到云端 API；会话可配置 system prompt 与 temperature，支持流式输出与中止。隐私优势是核心卖点：提示词与生成内容全程在本机处理，数据不出设备，规避了将用户数据发送给第三方大模型 API 的隐私合规风险；成本上省去按 token 计费的 API 调用，离线场景可用。边界：模型能力弱于云端大模型（适合摘要、分类、改写等轻任务）、依赖用户设备性能、能力随 Chrome 稳定版逐步推出（早期需 Origin Trial 注册），工程上按"内置 AI 做轻量任务、云端模型做重任务"分层。

答题框架是"API 形态 + 部署流程 + 隐私成本优势 + 能力边界"四点。能讲出能力检测降级与"轻任务本地、重任务云端"的分层策略，体现对实验性技术的务实态度。

• Baseline 的定义（两个主流浏览器链支持即进入）与四阶段
• 用 Baseline 标注（web.dev/status）评估特性可用性
• 特性决策流程：可用性、降级成本与灰度验证

Baseline 由 W3C WebDX 社区定义：新特性被浏览器实现后经历"Limited availability"（部分浏览器支持）、"Newly available"（Chrome/Edge、Firefox、Safari 两条浏览器链都支持）、"Widely available"（30 个月稳定）三阶段。工程价值：团队以 Baseline 为共同语言制定支持矩阵——需要"widely available"的特性可直接用（覆盖团队支持的浏览器），"newly available"评估后可用（多数用户浏览器已支持），Limited 阶段需特性检测与降级。特性决策流程：先查特性在 Baseline 的位置与支持矩阵匹配度；再评估降级成本（无 polyfill 时功能降级是否可接受）；高风险特性走灰度发布，用特性检测 + 运行时开关（如 Origin Trial）小流量验证后放开。原则是"基线决定可否直接用，降级成本决定怎么用"。

本题考"用标准化的支持数据做决策"：先解释 Baseline 三阶段，再落到"团队支持矩阵匹配 + 降级成本评估 + 灰度验证"的决策流程。答出 Limited/Newly/Widely 的差异即抓住概念核心。

• Popover API（popover 属性与 showPopover）的浮层能力
• CSS Anchor Positioning 的定位能力
• 原生能力对浮层类组件（tooltip/popover/menu）的替代边界

这三个 API 组合起来正在"吞掉"浮层类组件的实现空间：Popover API 提供原生浮层（popover 属性声明元素为浮层、showPopover()/hidePopover() 控制、自动顶层(top-layer)渲染、Esc 关闭、点击外部关闭），替代手写 portal + 遮罩 + 焦点管理的工具提示、下拉与菜单；CSS Anchor Positioning 用 anchor-name/position-anchor 把元素钉在锚点元素上，配合 position-area 与 inset-area 做边界避让，替代 JS 计算的浮层定位；Interest Invoker（invoketarget 属性）让按钮与浮层声明式绑定，悬停/聚焦触发。替代边界：静态结构、标准交互的浮层可直接用原生 API 显著减重；复杂场景（虚拟列表内浮层、跨组件状态联动、深度定制动画与主题）仍需组件库封装——但组件库的底层从"自己实现定位与浮层"变成"封装原生 API"，代码量、a11y 与边缘 case 大幅收敛。趋势是组件库变薄、原生能力变厚。

本题考"原生 API 对组件库的侵蚀"趋势：逐个讲清三个 API 的能力（浮层、锚定、触发），再给出"标准场景直接用、复杂场景组件库封装原生"的边界结论。能点出 top-layer 与焦点管理由浏览器负责是关键。

• 内置 AI（Prompt API）与 WebNN 本地推理的能力特征
• 隐私（数据不出设备）、离线、成本（免 token 费）维度对比
• 按任务类型与设备能力的混合选型策略

三个维度的对比：隐私上，内置 AI 与 WebNN 推理全部在本机执行，用户数据不出设备，满足敏感数据合规要求，第三方 API 需将数据送出设备（依赖供应商数据协议）；离线上，内置 AI 模型下载后完全离线可用，适合弱网与内网场景，第三方 API 强依赖网络；成本上，内置 AI 无 token 计费（一次性模型下载成本），第三方按量计费，高频轻量任务成本差异显著。选型边界：内置 AI 适合摘要、分类、实体抽取、翻译等轻量确定性任务，且模型能力（如 Gemini Nano）弱于云端大模型；WebNN 面向特定模型（如小型 embedding、分类器）的硬件加速推理；第三方 API 适合复杂推理、长上下文、多模态与需要持续迭代模型能力的场景。工程策略是分层混合：隐私敏感或高频轻量任务走本地、复杂创作与知识型任务走云端，用统一抽象层（同一调用接口）按能力检测与任务类型路由。

答题用"三维度对比 + 任务分层"结构：隐私/离线/成本讲清本地优势，模型能力与设备约束讲清边界，最后给出"本地轻任务 + 云端重任务 + 统一抽象"的混合方案，这是面试官想听的工程结论。

• 评估维度：成熟度（Baseline/标准状态）、收益、替代成本、降级风险
• 特性检测与渐进增强的采用路径
• 试点验证与回退预案的工程流程

评估框架分四步：一看成熟度——特性处于哪个标准阶段（W3C 候选推荐、浏览器实现状态、Baseline 阶段），实验特性需评估 Origin Trial 周期与团队可承受的实验风险；二看收益——解决什么问题、相对现有方案（库或手写）节省多少代码与运行时成本（如 OPFS 替代 IndexedDB 大文件存储、Navigation API 替代 history hack 做拦截）；三看替代成本——已有方案迁移的改动面、与新框架/新架构的兼容性；四看降级风险——不支持浏览器下的行为（View Transitions 无动画直切、Navigation API 回退 history 事件监听、OPFS 回退 IndexedDB），降级后功能是否完整。采用路径：先特性检测 + 渐进增强让新 API 只做增强层，再选一个低风险模块试点（埋点对比新旧方案的错误率与性能），数据验证后推广；始终保留回退预案。原则是"新 API 只做加法，价值不成立就不采用"。

本题考"新技术评估方法论"而非具体 API：成熟度、收益、替代成本、降级风险四维评估 + 试点验证流程。答出"渐进增强让新特性只做增强、降级路径功能完整"即为方法论到位。

• Baseline 的演进机制（新特性进入、Widely available 阶段）
• 跟踪渠道（web.dev/status、caniuse、Release notes）
• 特性采用节奏与团队规范化的结合

演进机制：新特性在两大主流浏览器链（Chromium 系与 Safari、Firefox 各算一条链）都实现后进入 "Newly available"，此后 30 个月无重大兼容问题升级为 "Widely available"；特性的状态随浏览器发布节奏持续更新，web.dev/status 与 MDN 的 Baseline 徽标实时反映。跟踪利用：团队应把 Baseline 状态纳入技术决策流程——开发新功能前查特性状态，Newly available 可评估采用（多数用户浏览器已支持）、Limited 阶段谨慎；把支持矩阵写进团队规范（如"widely available 才可默认使用，否则必须特性检测 + 降级"）；对实验特性（Origin Trial）明确登记与退出时间，避免长期依赖未标准化 API。基线演进对工程的意义是把"浏览器支持判断"从个人记忆变成共享的、可审计的标准数据，特性采用节奏可预测、可管理。

本题考"演进机制 + 团队规范"：先讲 Baseline 两阶段的时间轴（双链支持进入、30 个月转 widely），再讲跟踪渠道与"规范化的支持策略"。答出"把基线状态固化进团队规范"即体现落地意识。

• File System Access API（OPFS、目录句柄）与剪贴板 API（ClipboardItem、权限）
• Window Management / Screen Wake Lock 等多屏与设备 API
• 能力检测、权限模型与降级路径

三类 API 的能力：文件系统方面，File System Access API 提供 showOpenFilePicker/showSaveFilePicker 与目录句柄（同源持久化），OPFS（Origin Private File System）提供高性能同源存储（适合大文件、数据库落盘）；剪贴板方面，Clipboard API 的 writeText 之外还支持 ClipboardItem 写图片/富文本，读操作需用户授权（Permissions API）；多屏方面，Window Management API 枚举显示器（getScreenDetails）并移动窗口到指定屏幕，配合 Screen Wake Lock 保持屏幕常亮（视频、演示场景）。渐进采用要点：全部需能力检测（各 API 支持度差异大，如 OPFS 的同步/异步入口分裂）；权限模型——文件系统句柄与剪贴板读取都要用户手势与授权，降级路径要明确（剪贴板降级 execCommand 或提示手动复制、文件系统降级 input file + IndexedDB）；安全上下文中才可用（HTTPS）。工程原则是"新 API 做增强、权限失败不阻塞主流程、无 API 走成熟降级"。

答题按"能力枚举 + 统一采用策略"组织：三组 API 各讲一个代表能力，再统一讲能力检测、权限授权与降级路径。能答出"句柄持久化需用户手势、剪贴板读取要授权"即证明了解权限模型。

• @scope 的样式隔离能力与组件化意义
• text-wrap: balance/pretty 的排版优化
• scroll-driven animations 与 masonry（grid-template-rows: masonry）的现状

各特性影响与现状：@scope 用 CSS 原生作用域隔离样式（scope 起始/结束边界），替代 BEM/深层选择器的一部分职责，Chrome 118+、Safari 17.4+ 可用，帮助组件样式收敛；text-wrap: balance 让标题多行均匀（避免孤行），pretty 优化段落换行，Chrome 114+ 可用，是零成本排版升级；scroll-driven animations（animation-timeline）实现滚动进度动画，Chrome 115+、Safari 26+ 已支持，Firefox 仍未发布稳定支持；masonry 布局（grid-template-rows: masonry）目前仅 Chrome 实验支持（Flag），Safari 有实现但标准仍在讨论，落地远未成熟。工程影响：@scope 可逐步替换组件库的内部命名约定，text-wrap 可直接启用，滚动动画与 masonry 需特性检测降级（masonry 降级为多列或 JS 布局库）。总体原则是"按 Baseline 分批：可用的优化直接用、半支持的做增强、实验性的只试点"。

本题考"特性落地节奏"的分辨能力：哪些已广泛可用（text-wrap、@scope）、哪些半支持（滚动动画）、哪些实验（masonry）。逐个给出支持现状与降级方案即可体现对平台的实时认知。

• container-type/container 的单位（cqw/cqh）与查询条件
• :has() 的父级/兄弟选择能力与性能注意
• 项目规范：适用范围、命名、配合媒体查询的分层

成熟应用：Container Queries 让组件按"容器宽度"而非视口宽度响应——卡片网格、仪表盘小组件、侧边栏复用组件在不同容器下自适应，配合容器单位（cqw/cqh）做内部尺寸推导；:has() 让样式基于子元素/兄弟状态向上施加（.card:has(img) 加图版式、form:has(:invalid) 高亮表单、导航:has(.active) 加状态），是"父选子"的补全。项目规范要点：定义容器职责——只给确实需要容器自适应的组件设置 container-type（inline-size），避免全站容器嵌套导致查询语义混乱；容器命名（container-name）避免嵌套时查询误匹配；:has() 性能注意——选择器越靠右越具体、避免在热路径用昂贵组合（如 :has(> *) 全局），并配合层级限制；分层策略——视口级布局用媒体查询、组件级用容器查询、状态类用 :has()，三者各司其职。落地时把规范写进代码检查（lint 限制容器滥用）与设计系统文档。

本题考"成熟特性 + 工程规范"：先举真实应用场景（容器自适应、父选子），再给规范（容器命名与职责、:has 性能、与媒体查询分层）。答出"视口媒体查询 vs 容器查询"的分工即抓住要点。

• 特性检测（Feature Detection）与 UA 嗅探的取舍
• polyfill 的选择、维护与性能代价
• 灰度发布与监控的兜底机制

治理分三层：第一层特性检测——用运行时能力判断（typeof API 是否存在、CSS.supports()、@supports）决定行为分支，而非 UA 嗅探（UA 可伪装且粒度粗）；现代 CSS 用 @supports 做样式降级，JS 用能力检测 + 回退实现。第二层 polyfill 策略——按需、按版本：只对"收益大于代价"的特性打 polyfill（如 IntersectionObserver），评估 polyfill 的覆盖度（官方/社区、维护状态）、性能开销与体积（动态加载 polyfill 而非全量打包），标注"polyfill 不保证 100% 一致"的特性（如布局类）优先降级而非补全。第三层灰度与监控——新特性先对部分用户灰度（特性开关、地域/版本分桶），用 RUM 监控功能可用性与错误率，异常时快速回滚；监控项包含 polyfill 命中率与降级路径触发率，验证降级代码真实可用。原则是"检测决定分支、polyfill 按需补、灰度验证兜底"。

答题按"检测 → polyfill → 灰度"三层递进：检测用能力而非 UA、polyfill 按收益取舍且布局类特性降级优先、灰度加 RUM 兜底。答出"polyfill 也是运行时成本、要监控降级路径"即完整。

• 引擎差异的层面：CSS 实现、Web API、渲染行为、发布节奏
• 测试矩阵与自动化（跨引擎测试、真实设备）
• 兼容策略：分级支持、特性降级与回归防护

差异层面：CSS 新特性实现进度不同（如滚动驱动动画、masonry）、Web API 支持矩阵不同（如 Navigation API、File System Access）、渲染细节不同（字体渲染、布局边界 case、滚动行为、WebGL/Canvas 差异）、发布节奏不同（Chromium 每 4 周、Safari 跟随系统更新慢、Firefox 每 4 周）。兼容策略：一是明确分级支持——按用户占比定义"主支持浏览器"与"兼容浏览器"，主支持浏览器跑全量测试、兼容浏览器保证功能可用不保证像素一致；二是测试矩阵自动化——Playwright 跨引擎跑核心用例 + 真实设备/浏览器云做抽查，CI 中锁定回归；三是特性分级采用——按 Baseline 状态决定默认使用或降级，渲染细节差异（如滚动条、字体）接受差异或提供 CSS 归一化；四是监控兜底——RUM 按浏览器维度看错误率与性能，发现引擎特异问题快速定位。原则是"先分级、再测试、后监控，接受合理差异"。

本题考工程策略而非技术细节：讲清差异的四个层面后，落到"分级支持 + 跨引擎测试矩阵 + Baseline 分级采用 + RUM 监控"的体系。答出"兼容不等于像素一致、要按用户占比分级"即显工程成熟度。

• 标准流程：提案（WICG/WHATWG）→ 草案 → 候选推荐 → 推荐
• 浏览器实现、Origin Trial 与社区反馈的角色
• 工程师参与路径：反馈、测试、试用与提案

流程概览：特性通常先以 explainer 形式在 WICG/WHATWG 提出（描述问题、方案与开放问题），进入规范草案后浏览器厂商开始实现原型，经 Origin Trial 在真实站点试用收集反馈（API 形状据此调整），规范逐步推进到候选推荐与正式推荐，两个主流浏览器链都实现且稳定 30 个月后进入 Baseline。实现与标准化是交替推进的：反馈驱动修改、实现验证规范，绝大多数特性在此过程中被调整或废弃。工程师参与路径：一是试用与反馈——注册 Origin Trial 在真实产品试用，把 bug 与体验反馈提交给 Chromium/Firefox/Safari 的 issue 追踪器，这是最实际的影响方式；二是编写测试（web-platform-tests），测试即规范实现的一部分；三是提出新提案（写 explainer 并在社区讨论）；四是跟踪（MDN、web.dev/status、Baseline 仪表盘）保持团队认知同步。参与标准不是只有规范作者能做的事，试用反馈与测试贡献是普通团队的可行路径。

本题考对"标准化生态"的理解：讲清"提案 → 草案 → 试用 → 推荐 → Baseline"的演进，再落到工程师的具体参与方式（Origin Trial 反馈、wpt 测试、explainer）。答出"反馈驱动规范修改、实现与标准化交替"即显深度。

• 各类 API 的支持现状（File System Access、Web Bluetooth、Web Serial）
• 权限模型与安全限制（用户手势、权限提示、安全上下文）
• 采用决策：场景匹配、降级与生态支持

现状：File System Access（文件读写与目录句柄，Chromium + Safari 支持，Firefox 未实现）、Web Bluetooth（BLE 设备交互，Chromium 系支持）、Web Serial（串口通信，Chromium 系支持）、WebUSB、WebHID 同理——这类"平台能力 API"大多由 Chromium 系先行，Safari/Firefox 支持滞后或缺失，且只能在安全上下文（HTTPS）使用。采用考虑：一是场景匹配——设备类 API 面向特定行业应用（工业设备调试、医疗设备、实验室仪器），通用 Web 应用鲜有需求，先确认用户确实在支持的浏览器上；二是权限模型——全部需要用户手势触发授权，权限可撤销，需处理"拒绝授权"与"设备未连接"的降级流程；三是生态——配套的驱动能力（数据协议解析、错误码映射）需自建，跨浏览器缺失时评估 Electron/原生壳的替代方案。原则是"能力 API 按需评估、权限体验设计优先、Chromium 为主的场景才值得投入"。

答题结构：现状（Chromium 系先行、Safari/Firefox 缺失）→ 采用考虑（场景、权限、降级）→ 结论（按需投入）。答出"安全上下文与用户手势授权"这两个硬约束即抓要点。

• WebGPU 的架构定位（现代 GPU API、Compute Shader、跨平台）
• 与 WebGL 的关系与迁移路径
• 工程采用：支持现状、降级与适用场景

现状：WebGPU 是新一代浏览器图形/计算 API，由 W3C WebGPU 工作组制定，Chromium 系已默认支持、Safari 26+ 也已支持（Firefox 141+ 已默认支持），提供现代 GPU 能力——计算着色器（Compute Shader）做 GPGPU 计算（AI 推理、物理模拟、数据处理）、独立的渲染管线描述、资源绑定模型与跨平台后端（底层映射 Vulkan/Metal/D3D12）。与 WebGL 的关系：WebGL 2 是 OpenGL ES 的浏览器封装，能力与性能受旧管线模型限制；WebGPU 是面向现代 GPU 架构的完整重写，性能（Draw Call 开销、计算能力）显著更强，但 API 更底层、学习成本高。演进意义：Web 图形从"游戏引擎特化"走向"通用计算平台"——浏览器内跑机器学习、3D 应用、视频处理成为可能，配合 Wasm 可做高性能应用。工程采用：Web 3D 应用评估 WebGPU 提升（复杂场景渲染、计算负载），用 WebGPURenderer 类封装实现 WebGL 回退；通用应用先用 WebGL/Canvas 保持兼容，WebGPU 作为增强层逐步引入。原则是"WebGPU 是能力上限的扩展，不是现有方案的强制替代"。

本题考图形平台演进认知：WebGPU 的定位（现代 GPU API + 计算能力）、与 WebGL 的差异、以及"渲染器封装 + 回退"的工程路径。答出计算着色器带来的 GPGPU 场景即超出表面认知。

• 第三方 Cookie 移除的时间线与驱动因素（隐私沙箱）
• 替代方案：CHIPS、Storage Partitioning、FedCM、Attribution Reporting
• 工程应对：检测、迁移与降级监控

背景与时间线：出于隐私考虑，Chrome 推进逐步禁用第三方 Cookie（曾多次延期，最终按用户群分阶段淘汰），Safari（ITP）与 Firefox（ETP）早已默认拦截第三方 Cookie；驱动因素是隐私沙箱（Privacy Sandbox）系列替代 API。替代方案：同站点跨域子资源用 CHIPS（分区 Cookie）保留最小状态；跨站认证用 FedCM（联合凭据管理）替代第三方 Cookie 登录态；广告归因用 Attribution Reporting API；存储访问用 Storage Access API 申请；通用站点数据改用 Storage Partitioning 后的分区存储。工程应对三步：第一步盘点——审计第三方 Cookie 的使用点（登录、埋点、广告、跨站 iframe 通信），分类标记；第二步迁移——认证走 FedCM/自有域代理、埋点改用 First-Party 数据 + 分区方案、跨站状态用 postMessage/Storage Partitioning；第三步监控——用 Chrome 的 cookie 排除提示与 RUM 检测登录失败率、转化率回退，灰度验证后再全量。原则是"尽早盘点，认证与埋点是迁移重点"。

本题考"平台政策变化的前端应对"：时间线讲清渐进淘汰，替代方案按场景对应（认证 FedCM、分区 CHIPS、归因 Attribution），工程应对按"盘点 → 迁移 → 监控"三步。答出各替代 API 的使用场景即可。

• 各浏览器发布节奏的差异（Chromium 4 周、Safari 随系统、Firefox 4 周）
• 节奏差异对新特性普及速度的影响
• 对特性采用决策与 polyfill 生命周期的具体影响

节奏现状：Chromium 从 6 周缩短到 4 周稳定发布（Stable 每 4 周），Firefox 同样 4 周，Safari 跟随 macOS/iOS 系统更新（每年大版本 + 小版本滚动，用户升级依赖系统升级，普及慢）。影响链条：发布节奏决定特性"实现时间"（Chromium 快）与"到达用户时间"（Safari 依赖系统更新，旧系统用户可能数年停留在旧引擎），因此新特性在 Chromium 一统的站点可快速采用，但涉及 Safari 用户的特性要按"支持达成时间"而非"实现时间"规划。对采用决策：用 Baseline 看"双链达成"时刻，规避"Safari 永远慢半拍"的误判；对 polyfill 策略：Safari 升级慢意味着 polyfill 生命周期被拉长（同一 polyfill 需要维护更久），决策时把"该特性在 Safari 的普及速度"计入成本，优先采用 Safari 已跟进的特性，长期未跟进的特性（如部分实验 API）直接用降级而非 polyfill。原则是"按用户实际的引擎分布规划采用时间表，polyfill 维护期按最慢的升级节奏估算"。

本题考"节奏 → 策略"的推导：先讲节奏差异（Safari 随系统升级慢），再推导出"到达用户时间"决定采用时间表与 polyfill 维护期。答出 Safari 升级模型对 polyfill 生命周期的放大效应即显洞察。

• anchor-name/position-anchor 与 position-area/inset-area 的声明式定位
• 与 Popover API、Interest Invoker 组合的零 JS 浮层
• 边界避让（overflow 自适应）、支持现状与降级

实现方式：锚点元素声明 anchor-name: --btn，浮层元素用 position-anchor: --btn 绑定锚点，position-area（或 inset-area）指定相对锚点的区域（如 bottom span-right 表示底部对齐），浏览器自动完成定位；边界处理用 position-try-fallbacks 定义候选位置，空间不足时自动切换（如底部放不下转顶部），替代 JS 的碰撞检测。与 Popover API（popover 属性 + popovertarget 触发）组合后，tooltip/popover 从"JS 定位 + JS 显隐 + JS 焦点管理"变成纯声明式 HTML/CSS：按钮 popovertarget 声明绑定，浮层 popover 声明浮层语义，CSS 声明锚定与避让。边界：Safari 16.4+/Chrome 125+ 支持（Firefox 部分支持 position-area）、position-try-fallbacks 的兼容差异、锚点元素在滚动容器中的行为、动态尺寸内容需谨慎；不支持时降级为简单绝对定位（内容不越界时仍可用）或保留 JS 定位方案。价值是浮层类组件回归"语义化 + 声明式"，定位逻辑从 JS 移除。

本题考"声明式替代命令式"的完整链路：anchor 声明绑定、position-area 定位、position-try 避让、popover 显隐四件套组合出零 JS 浮层；再讲支持现状与降级。答出 position-try-fallbacks 的自动避让即核心。