浏览器能力组合

共 19 题
📑 题目列表 19 题
#
★★★

1. 本地存储与离线,IndexedDB 与 Cache API?

本地存储与离线能力中,IndexedDB 与 Cache API 的定位分别是什么?二者如何协作支撑离线应用?

  • IndexedDB 面向结构化数据、Cache API 面向请求/响应
  • 与 localStorage 的容量与异步差异
  • Service Worker 中的离线组合模式

IndexedDB 是浏览器内置的事务型 NoSQL 数据库,面向结构化数据(对象、索引、游标、事务),容量大、异步、支持持久化请求(navigator.storage.persist),适合存业务数据;Cache API 面向"请求→响应"对,专为 HTTP 资源设计,与 Service Worker 深度集成,适合缓存页面资源与 API 响应。离线应用的标准组合是:Service Worker 的 fetch 拦截先用 Cache API 命中资源(App Shell 与静态资源),业务数据走 IndexedDB,必要时配 Background Sync 在联网后回传。localStorage 只适合小量同步字符串,不能承担离线存储职责。

考察离线存储体系的分工:Cache API 管"网络层资源",IndexedDB 管"业务层数据",二者通过 Service Worker 协作构成离线能力闭环,需与 localStorage 的容量与同步语义区分。

// Service Worker 中组合使用 Cache API 与 IndexedDB
self.addEventListener('fetch', (e) => {
  e.respondWith((async () => {
    const cached = await caches.match(e.request);
    if (cached) return cached;
    const res = await fetch(e.request);
    const cache = await caches.open('app-shell');
    cache.put(e.request, res.clone());
    return res;
  })());
});
#
★★

2. Media Capabilities API(decodingInfo/encodingInfo)在媒体能力探测、清晰度自适应与省电(powerEfficient)选择中的工程价值?

Media Capabilities API 的 decodingInfo/encodingInfo 在媒体能力探测、清晰度自适应与省电(powerEfficient)选择中有怎样的工程价值?

  • decodingInfo/encodingInfo 的输入输出与能力分级
  • 基于能力的清晰度自适应(quality 建议)
  • powerEfficient 驱动的省电决策

Media Capabilities API 通过 navigator.mediaCapabilities.decodingInfo()/encodingInfo() 查询"浏览器+硬件"组合下某媒体配置(编解码器、分辨率、码率、内容类型)的支持等级:supported、smooth(能否流畅播放)、powerEfficient(是否硬件加速省电)。工程价值:播放器初始化时先探测候选档位,选择 smooth && powerEfficient 的配置;自适应流(HLS/DASH)切换清晰度时优先"流畅且省电"的组合,避免盲目追求高码率导致掉帧与耗电;编码端(录制、转码)用 encodingInfo 决定是否启用硬件编码。注意探测结果是建议而非承诺,仍需以真实播放回调兜底。

考察媒体能力探测的工程应用:decodingInfo 输出 supported/smooth/powerEfficient 三维度,供清晰度自适应与硬件加速选择,答案需说明探测到决策的映射与兜底。

#
★★

3. Custom Elements 的定义升级、构造约束、connectedMoveCallback 与自定义元素反应队列会怎样影响框架渲染时序

Custom Elements 的定义升级、构造约束、connectedMoveCallback 与自定义元素反应队列会怎样影响框架渲染时序?

  • customElements.define 的定义升级限制与构造器约束
  • connected/disconnected 移动场景与反应队列的时序
  • 对框架渲染(hydration、批量更新)的影响

Custom Elements 的构造器受约束:必须调用 super()、不能使用脚本标签创建、且每个标签只能 define 一次(重复定义抛 NotSupportedError,但可升级已存在元素)。框架渲染时序受反应队列影响:连接(connectedCallback)、属性变化(attributeChangedCallback)等回调由浏览器按微任务/渲染时机批量派发,元素在 DOM 中移动(如列表重排、hydrate 时 attach)会先触发 disconnectedCallback 再 connectedCallback(connectedMoveCallback 提案则把"移动"作为独立回调减少重复初始化)。框架需据此设计:初始化逻辑幂等、避免在回调中触发同步布局与重复订阅,渲染批处理与自定义元素回调的时序差异会造成"状态已更新但视图未同步"的间隙。

考察自定义元素生命周期与框架渲染的交汇点:构造约束、define 唯一性、回调的批量派发与移动语义共同影响 hydration 与更新时序,答案需体现幂等初始化与批次感知。

#
★★

4. Declarative Shadow DOM 经服务端输出后,客户端应如何复用已有 shadow root,避免重复 attachShadow、样式闪烁和事件重复绑定

Declarative Shadow DOM 经服务端输出后,客户端应如何复用已有的 shadow root,避免重复 attachShadow、样式闪烁和事件重复绑定?

  • DSD 的模板解析与 attachShadow 的复用规则
  • 客户端 hydration 时对已有 shadow root 的探测
  • 样式闪烁(FOUC)与事件重复绑定的规避

Declarative Shadow DOM 让服务端直接输出 与 shadow 内容,浏览器解析时自动创建 shadow root,样式随首屏 HTML 直达,消除客户端渲染的样式闪烁。客户端 hydration 时不能再无条件 attachShadow——需要先检查 element.shadowRoot 是否存在并复用,否则抛错(已有 shadow root 时 attachShadow 会报错);事件绑定用"一次性初始化 + 幂等注册"模式(或依赖信号重放)避免重复。注意 Shadow DOM 的样式隔离会让外部样式表失效,需要把关键样式内联进 DSD 或在 shadow 内引用共享样式。

考察 DSD 的 hydration 实践:复用已有 shadow root 是硬约束,答案需覆盖"探测-复用-幂等绑定"流程与样式闪烁的成因和消除手段。

// 复用 DSD 输出的 shadow root,避免重复 attachShadow
class MyCard extends HTMLElement {
  connectedCallback() {
    if (!this.shadowRoot) {
      this.attachShadow({ mode: 'open' }); // 仅无 DSD 时兜底
    }
    // 事件绑定与初始化必须幂等
    this.setupBindings();
  }
}
#
★★

5. Storage Buckets 的 durability、expires、quota 与独立清除语义如何支持多租户离线数据的生命周期管理

Storage Buckets 的 durability、expires、quota 与独立清除语义如何支持多租户离线数据的生命周期管理?

  • Storage Buckets 的分桶与按桶配置语义
  • durability(best-effort/strict)与 expires 过期语义
  • 按桶清除与配额管理的多租户价值

Storage Buckets API 把站点存储划分为独立命名桶,每个桶可单独配置:durability(best-effort 高性能可丢失 vs strict 持久优先)、expires(绝对过期时间)、quota(桶容量上限),并支持按桶单独清除(deleteBucket)与遍历。多租户离线场景的价值:为不同业务模块(聊天、缓存、大文件)建立独立桶,配不同持久性与过期策略,如临时缓存用 best-effort + expires、重要草稿用 strict;浏览器压力回收时按桶优先级清除,避免"一个模块的缓存挤爆所有存储";quota 分配防止单一租户耗尽总配额。

考察 Storage Buckets 的工程语义:按桶配置持久性、过期与配额,按桶独立清除,回答需落到多租户生命周期治理的具体映射。

#
★★

6. WebTransport 的双向流、单向流和 Datagram 在丢包、乱序、背压及连接迁移时应采用什么应用层语义

WebTransport 的双向流、单向流和 Datagram 在丢包、乱序、背压及连接迁移时应采用怎样的应用层语义?

  • 流(可靠有序)与 Datagram(尽力而为)的协议差异
  • 背压传播与流关闭的应用层处理
  • 连接迁移(网络切换)时的会话恢复策略

WebTransport 提供三类信道:双向流(bidi)、单向流(unidirectional)与 Datagram。流基于 QUIC stream,可靠有序、有背压——读取端不消费时写入端 receive 队列受限,应用层应让消费速率匹配生产速率,并用流关闭(FIN/重置)表达消息边界与错误;Datagram 尽力而为、可能丢包乱序,适合实时位置、游戏状态等可容忍丢失的数据,需自带上层序号与去重。丢包与乱序语义:流交给 QUIC 重传保证顺序,Datagram 由应用自行处理。连接迁移(Wi-Fi↔蜂窝)时 QUIC 保持连接,但应用层需设计会话恢复(重发未确认状态、重新订阅),并监听 close/error 做降级到 WebSocket 的回退。

考察 WebTransport 的应用层建模:流可靠有序有背压、Datagram 尽力而为,答案需分别给出丢包乱序、背压与连接迁移下的语义设计。

#
★★

7. WebCodecs 的 VideoFrame、EncodedVideoChunk、transfer 与 close 如何组织,才能避免跨 Worker 管线中的帧泄漏和复制放大

WebCodecs 的 VideoFrame、EncodedVideoChunk、transfer 与 close 如何组织,才能避免跨 Worker 管线中的帧泄漏和复制放大?

  • VideoFrame 的资源所有权与 close 语义
  • postMessage 的 transfer 转移 vs 结构化克隆
  • 帧管线的生命周期设计(生产-传输-消费-释放)

VideoFrame 持有 GPU/系统内存资源,必须显式 close 释放,否则泄漏显存;资源可以转移(transferable)而非复制——postMessage(frame, [frame]) 转移所有权,避免跨 Worker 管线中的复制放大。管线组织原则:生产端创建帧后立即 transfer 给下游,自己不再使用;消费端处理完毕(渲染或编码进 EncodedVideoChunk)后 close;用"帧池"限制在途帧数量,配合队列长度反馈背压;每个帧有唯一生命周期跟踪(如计数器)防止双 close 与悬挂帧。编码输出 EncodedVideoChunk 同样是 transferable 的资源型对象,同理需要及时释放。

考察 WebCodecs 的资源管理:transfer 避免复制、close 避免泄漏、帧池加背压控制在途数量,回答需给出完整生命周期闭环。

// 跨 Worker 转移 VideoFrame 所有权,消费后 close
// 主线程
worker.postMessage({ frame }, [frame]); // 转移所有权
// Worker
worker.onmessage = ({ data }) => {
  const frame = data.frame;
  encoder.encode(frame); // 消费
  frame.close();         // 释放资源
};
#
★★

8. WebGPU 设备丢失、验证错误和显存预算变化时,渲染或推理任务怎样重建设备并恢复可见状态

WebGPU 设备丢失、验证错误和显存预算变化时,渲染或推理任务应怎样重建设备并恢复可见状态?

  • requestAdapter/requestDevice 与 device.lost 事件
  • 验证错误(validation error)的处理边界
  • 设备重建与可见状态恢复流程

WebGPU 设备可能因驱动重置、显存压力等原因丢失,通过 device.lost 异步通知;验证错误(非法管线、越界绑定)会向 uncapturederror 报告并可捕获。恢复流程:监听 lost 事件,暂停渲染/推理循环、释放旧资源(缓冲、纹理、管线),重新 requestAdapter/requestDevice 建新设备,再重建必需资源与管线;可见状态(场景图、业务数据)保存在应用层而非 GPU 侧,重建后据此重绘,避免"GPU 状态丢失即应用状态丢失"。显存预算变化(device.lost 前的压力信号)应主动降级:降低纹理分辨率、缩减帧缓冲。关键:所有 GPU 资源在重建周期内标记失效,禁止继续提交命令到旧队列。

考察 WebGPU 的故障恢复工程:lost 事件驱动重建、验证错误可捕获、应用状态与 GPU 资源分离,答案需给出"暂停-释放-重建-恢复"的完整流程。

#
★★

9. WebNN 图编译前应怎样探测算子、数据类型和设备能力,并为不支持的节点生成 WASM 或服务端回退

WebNN 图编译前应怎样探测算子、数据类型和设备能力,并为不支持的节点生成 WASM 或服务端回退?

  • MLContext 的算子与数据类型能力探测
  • 图编译(build)失败时的节点级降级
  • WASM 算子回退与服务端回退的分层

WebNN 是图式 API:先构造 MLGraphBuilder 的算子图,再编译(build)为 MLGraph。编译前需探测能力:遍历模型算子逐一检查 MLContext 支持的算子集、数据类型(fp32/fp16/int8)与设备类型(CPU/GPU/NPU),用 opSupportLevel 或构建尝试判断。降级分层:不支持的节点替换为自定义 WASM 实现(把子图拆出,用 WASM 算子计算后接回图),全图不支持或精度不满足时走服务端推理(上传输入、拉取输出),并缓存图与探测结果避免重复编译。工程上把模型切分为"受支持子图 + 回退节点"两段执行,统一为异步管线。

考察 WebNN 的工程落地:能力探测先行、节点级降级(WASM)与整图回退(服务端)分层,答案需说明探测对象与两段执行设计。

#
★★

10. Chrome Built-in AI 的模型可用性、下载状态与用户激活要求如何和 WebNN/WebGPU 的算子加速职责分层

Chrome Built-in AI 的模型可用性、下载状态与用户激活要求如何与 WebNN/WebGPU 的算子加速职责分层?

  • Built-in AI 的模型下载与可用性状态机
  • 用户激活(user activation)与权限要求
  • 与 WebNN/WebGPU 的职责分层(模型服务 vs 算子加速)

Chrome Built-in AI(如 Prompt API、Translator API)由浏览器内置模型提供服务:模型可能未下载、下载中或已可用,需通过 availability 状态与下载进度事件管理;部分能力要求用户激活(用户手势触发会话创建)与页面安全上下文,权限策略约束站点使用。职责分层:Built-in AI 负责"模型生命周期"(下载、版本、运行时管理),WebNN/WebGPU 是"底层算子加速器"——自定义推理管线直接写 WebNN 图或 WebGPU 着色器获得算子级控制;内置 API 内部可能也走这些后端。选型:要快速稳定的标准能力用 Built-in AI,需自定义模型或算子级优化时用 WebNN/WebGPU 自建管线,二者按"模型服务 vs 加速后端"分层互补。

考察 AI 平台能力的边界:Built-in AI 是模型服务层(含下载与激活约束),WebNN/WebGPU 是加速层,答案需分层说明职责与选型。

#
★★

11. 浏览器能力检测 vs 特性检测,如何优雅降级?

浏览器能力检测与特性检测有何区别?如何基于二者实现优雅降级?

  • 能力检测(UA 解析)与特性检测(API 探测)的差异
  • 特性检测的组合与优先级
  • 优雅降级与渐进增强的实现路径

能力检测指解析 User-Agent 判断"是什么浏览器",脆弱且易伪造,只能作兜底;特性检测指运行时探测"是否有某能力"(typeof、'in' 运算符、能力执行验证),是可靠的判断手段。优雅降级路径:优先特性检测——用 '@supports'、'in' 与安全执行探测 API 存在性与行为,分档渲染(完整能力/降级能力/基础功能);特性检测无法覆盖的(如引擎 bug)再辅以能力检测白名单;所有路径都保留基础可用性(语义 HTML、无 JS 可读)。组合模式:detect → load(按需加载 polyfill 或降级模块)→ render 三阶段,避免"检测后仍使用不存在的 API"。

考察降级策略的核心方法论:特性检测优先、UA 兜底,配合"检测-加载-降级"三阶段模式,答案需强调基础可用性兜底。

#
★★

12. Compute Pressure API(ComputePressureObserver)在基于 CPU 负载动态调整渲染精度、降级动画与采样策略的工程价值,与性能监控的区别

Compute Pressure API 在基于 CPU 负载动态调整渲染精度、降级动画与采样策略上有何工程价值?它与性能监控有何区别?

  • ComputePressureObserver 的负载档位与回调机制
  • 按负载档位降级渲染精度、动画与采样率
  • 与 RUM/performance API 监控的定位区别

Compute Pressure API 通过 new ComputePressureObserver(callback, { cpuUtilizationThresholds, cpuSpeedThresholds }) 订阅 CPU 负载档位变化(nominal/fair/serious/critical),回调中按档位调整策略:serious 时降低动画帧率、减少粒子数量、降低渲染分辨率与采样频率,critical 时暂停非必要任务,释放 CPU 给用户任务。与性能监控的区别:性能监控(PerformanceObserver、RUM)是"事后度量",记录耗时与指标用于分析;Compute Pressure 是"实时状态信号",用于运行时主动调节,且聚合系统级负载而非单页指标。工程价值是把"负载感知"接入渲染循环,实现响应式降级,避免用户设备过热或卡顿。

考察运行时资源自适应:Compute Pressure 是实时调节信号,性能监控是事后度量,答案需区分二者并给出按档位降级的具体策略。

#
★★

13. URLPattern API(Baseline)在路由匹配、链接审计与参数提取中替代正则的工程价值及边界

URLPattern API 在路由匹配、链接审计与参数提取中替代正则的工程价值是什么?其边界在哪里?

  • URLPattern 的路径、搜索、hash 分段匹配能力
  • 具名组与参数自动提取对可读性的提升
  • 边界:完整 URL 语义、协议差异与 polyfill

URLPattern 以声明式模式匹配 URL 的 protocol、hostname、pathname、search、hash 分段,支持具名组(:id)、可选组、正则片段,并自动提取参数对象,替代手写正则的路由匹配与参数解析,可读性与可维护性显著提升;可用于路由库底层、链接审计(批量校验站点内链合法性)、权限与重写规则。边界:它是规范语义的 URL 解析而非纯字符串匹配,模式需符合 URL 结构;Baseline 覆盖现代浏览器,旧环境需 polyfill(web 包 urlpattern-polyfill);复杂校验(如国际化域名、编码差异)仍要结合 URL 标准解析。

考察 URLPattern 的适用场景与边界:分段声明式匹配与参数提取是核心价值,答案需说明 URL 语义约束、Baseline 覆盖与 polyfill 兜底。

#

14. 实时媒体 AI 管线怎样串联 WebCodecs、WebGPU/WebNN 与 WebTransport,同时限制帧队列长度和端到端延迟

实时媒体 AI 管线怎样串联 WebCodecs、WebGPU/WebNN 与 WebTransport,同时限制帧队列长度和端到端延迟?

  • 解码→推理→编码→传输的管线串联
  • 帧队列长度与背压控制
  • 端到端延迟的预算分配与自适应

实时管线典型链路:WebCodecs 解码(VideoDecoder)→ WebGPU/WebNN 推理(AI 处理,如分割、超分)→ WebCodecs 编码(VideoEncoder)→ WebTransport 发送(Datagram 或流)。端到端延迟控制:每级之间用固定容量队列,队列满即丢帧(旧帧优先丢弃)形成背压,禁止无界排队;推理用双缓冲(当前帧计算、下一帧解码)隐藏延迟;按延迟预算分配各级时间片(解码 ≤ X ms、推理 ≤ Y ms、编码 ≤ Z ms),超预算时降级(降分辨率、简化模型、跳过非关键帧)。测量用 performance 打点跟踪每帧时间戳,实时调整预算。

考察实时管线工程:串联链路、有界队列背压、丢帧策略与延迟预算分配,答案需体现"延迟预算驱动降级"的系统设计。

#

15. 浏览器能力矩阵如何统一表达安全上下文、跨源隔离、权限策略、用户授权、硬件限制与降级路径

浏览器能力矩阵如何统一表达安全上下文、跨源隔离、权限策略、用户授权、硬件限制与降级路径?

  • 能力前置条件的多维度建模
  • 统一矩阵的结构(能力×前置条件×降级)
  • 运行时逐项校验与降级路径映射

许多 API(如 navigator.storage、WebGPU、持久化存储)的可用性取决于多层前置条件:安全上下文(HTTPS/localhost)、跨源隔离(COOP/COEP 头,SharedArrayBuffer 等需要)、权限策略(Permissions-Policy 允许)、用户授权(权限请求结果)、硬件限制(设备能力、显存)。统一矩阵以"能力"为行、以"前置条件"为列,单元格记录条件满足时的可用版本与不满足时的降级路径(polyfill、禁用功能、替代方案)。运行时按矩阵逐项校验(isSecureContext → crossOriginIsolated → permissions → 能力探测),返回"当前可用等级",UI 据此渲染功能开关与提示,确保任何环境下都有明确行为。

考察能力前置条件的系统化表达:多维条件矩阵与逐项校验、降级路径映射,答案需说明矩阵结构与运行时判定流程。

#

16. Web API 的组合,离线、通知与后台任务的协同?

离线、通知与后台任务等 Web API 如何协同构成完整的"应用常驻"能力?

  • Service Worker、Push、Notification 与 Background Sync 的职责
  • 离线优先与后台同步的协同流程
  • 各 API 的触发时机与限制(生命周期)

协同体系:Service Worker 提供离线缓存与后台执行上下文;Push API 接收服务端推送(即使页面关闭);Notification API 展示用户可见通知;Background Sync(含 Periodic Background Sync)在联网后重放队列任务;配合 IndexedDB 保存待同步数据。典型流程:用户离线操作写入本地队列并注册 sync 事件 → 联网后 Service Worker 触发 sync 回传数据 → 服务端异步处理完成可推 Push → 页面收到 push 展示 Notification。注意各 API 的限制:Push/通知需用户授权,后台任务受浏览器节流(生命周期、站点隔离、节能模式)影响,通知点击回调只能唤醒受限上下文,需设计"渐进提升"路径。

考察离线与后台能力的组合设计:SW+Push+Notification+Sync 各司其职形成闭环,答案需说明协作流程与各环节的用户授权与节流约束。

#

17. Web Worker 与主线程协作,消息与 Transferable?

Web Worker 与主线程如何协作?消息传递与 Transferable 对象应如何使用?

  • postMessage 的克隆语义与 Transferable 转移
  • 结构化克隆 vs 转移的性能差异
  • 协作模式:计算下沉、所有权转移与共享内存

主线程与 Worker 通过 postMessage 通信:默认结构化克隆(拷贝),适合小数据;大对象(ArrayBuffer、MessagePort、OffscreenCanvas、VideoFrame 等 Transferable)通过 transfer 列表转移所有权,零拷贝但转移后原线程不可再访问。协作模式:重计算下沉到 Worker 并回传结果;大缓冲在管线级转移所有权(谁持有谁消费);需要共享可变状态时用 SharedArrayBuffer + Atomics(需跨源隔离)。工程要点:明确所有权归属避免双重使用,控制消息频率(批量/节流),用 MessageChannel 建立专用通道,Worker 内的错误用 error 事件上报。

考察 Worker 通信机制:克隆与转移的性能差异、所有权语义与协作模式,答案需强调 Transferable 的零拷贝与所有权约束。

const sab = new ArrayBuffer(1024 * 1024);
worker.postMessage({ buf: sab }, [sab]); // 转移所有权,零拷贝
// 转移后主线程不能再访问 sab
#

18. 能力组合的降级,特性检测的优先级?

能力组合的降级中,特性检测应遵循怎样的优先级?

  • 先检测强约束条件(安全上下文、权限)再检测 API
  • 分级检测:存在性→行为→性能
  • 降级链的优先级设计

特性检测的优先级设计原则:先检测"硬前置条件"再检测"API 本体"——如先查 isSecureContext、crossOriginIsolated,再查 API 存在性;检测分三级:存在性(typeof/in)、行为(能否安全执行并产生预期结果,防止"存在但坏掉")、性能/可用性(如硬件加速状态)。降级链按"能力完整度"排序:完整能力 → 降级实现(polyfill/WASM)→ 基础功能 → 禁用并提示,每个层级都有明确判定条件;同一功能多个候选 API 时按"最优→最差"顺序探测,且探测成本低、可缓存。

考察降级检测的方法论:先约束后本体、存在性-行为-性能分级、能力完整度排序的降级链,答案需体现检测顺序与成本控制。

#

19. 能力检测的时机,为何部分 API(权限、GPU、存储配额)在页面加载态与用户激活后的能力不同,检测-加载-降级的组合模式如何设计?

能力检测的时机为何重要?部分 API(权限、GPU、存储配额)在页面加载态与用户激活后的能力为何不同?检测-加载-降级的组合模式如何设计?

  • 用户激活(user activation)对能力开放的影响
  • 权限请求时机与持久授权
  • 检测-加载-降级的时机编排

部分能力受"用户激活"门控:如 GPU 高负载任务、全屏、部分 AI API 在无用户手势时受限;权限(navigator.permissions)在页面加载时可查询"当前状态",但请求权限通常需要用户手势,授权后能力才开放;存储配额(navigator.storage.estimate)在首次写入前后、持久化请求后结果不同。因此"加载态检测"与"激活后检测"结论可能不同。组合模式:加载期做低成本探测(是否安全上下文、API 是否存在、权限状态),把结果缓存为能力快照;用户交互期(手势处理器中)再请求权限、初始化 GPU 等重能力并更新快照;降级路径按快照分档渲染,避免"加载期说可用、点击后不可用"的体验断裂。

考察能力检测的时机编排:加载期低成本探测、激活期重能力初始化、快照驱动的分级渲染,答案需说明为何同一 API 两个时机的结论不同。