离线同步与 Web Push

• IndexedDB 的结构化存储模型（对象仓库、索引、事务）
• 离线数据的读写与查询模式
• 异步 API 的工程封装与兼容

IndexedDB 是 PWA 离线数据的主存储：存结构化对象（用户数据、离线队列、草稿、缓存元数据），容量远大于 localStorage（可达数百 MB 至 GB 级），支持索引查询（按字段建索引、游标范围遍历）与事务（readonly/readwrite 保证多操作原子性）。工程价值：离线优先架构的"数据底座"——离线写入先落 IndexedDB，联网后同步；缓存元数据与业务数据分离管理；配合 SW 在后台读写（SW 与页面共用同源 IndexedDB）。使用要点：API 是异步的（request 回调/IDB 包装成 Promise），事务在事件循环内自动提交（勿在事务外异步操作同一事务）；索引与唯一约束设计影响查询性能；存储清理策略（版本迁移 onupgradeneeded、容量估算）；异常处理（QuotaExceededError、事务 abort）；可用 idb 等轻封装库减少样板代码。兼容性：现代浏览器全支持，iOS Safari 的稳定性与容量需实测降级。

回答按"存储模型 → 离线工程价值 → 事务/索引正确用法 → 封装与兼容"组织，突出"原子事务"与"异步封装"两个易错点。

• VAPID 密钥对与 JWT 签名
• PushManager.subscribe 的订阅创建
• 权限申请与推送链路闭环

Push API 链路：生成 VAPID 密钥对（公钥/私钥）→ 前端申请 Notification 权限后，SW 用 navigator.serviceWorker.ready.then 调 pushManager.subscribe({userVisibleOnly: true, applicationServerKey: 公钥}) 得到 PushSubscription（含 endpoint 与 keys）→ 把订阅信息 POST 到应用服务器 → 服务器发推送时用私钥签 JWT（RFC 8292）请求 endpoint（推送服务），payload 用订阅公钥加密（RFC 8291）→ 推送服务投递到设备 → SW 的 push 事件处理。工程要点：userVisibleOnly 必须 true（每条推送需可见通知，防滥用）；applicationServerKey 是 VAPID 公钥（可轮换，轮换需重新订阅）；权限申请时机影响转化；订阅保存与同步；VAPID 私钥必须保密（泄漏可被伪造推送），存服务端密钥管理。DevTools 的 Application 面板可查看订阅 JSON 与推送测试。

回答按"端到端链路（密钥→订阅→签名发送→投递→事件）→ 工程要点 → 安全"组织，突出 VAPID 公私钥与 userVisibleOnly 两个关键约束。

• App Shell（外壳）与内容的分离
• 外壳的预缓存与离线可用
• 离线 fallback 的兜底策略

App Shell 模型把应用拆为"外壳"（导航、框架、静态骨架 UI）与"内容"（动态数据）：外壳在安装时预缓存（HTML 入口、CSS、JS、图标），加载后秒开，内容按需从网络/缓存填充；配合 SW 的导航请求策略（NetworkFirst 降级缓存），实现"壳离线、内容在线优先"。离线 fallback 页面是兜底：导航请求离线且未命中缓存时，SW 返回预缓存的 fallback.html（提示离线状态、展示缓存过的内容入口、引导重试），避免浏览器默认错误页。工程要点：fallback 页面本身预缓存且不含动态依赖；区分"导航 fallback"与"资源 fallback"（资源缺失返回占位图而非错误）；fallback 页提供"重试/查看离线缓存"操作；外壳更新走 SW 版本化，内容区用 stale-while-revalidate 兼顾新鲜与速度。价值：App Shell 让首屏与导航不依赖网络，离线体验从"不能用"变"可用核心功能"。

回答按"模型定义（壳与内容分离）→ 缓存与加载策略 → fallback 设计 → 更新与内容策略"组织，核心是"静态壳预缓存 + 动态内容分级缓存"。

• RFC 8292 的 VAPID JWT 签名
• RFC 8291 的 payload 加密（AES-GCM）
• 投递链路与 SW 解密消费

完整工作流分三段：订阅段——前端获得 PushSubscription（endpoint、p256dh 公钥、auth 密钥）并上报服务端保存；发送段——应用服务器用 VAPID 私钥生成 JWT（RFC 8292：aud 为推送服务 origin、exp 时效），连同 payload 用订阅公钥做加密（RFC 8291：基于 ECDH 协商密钥 + AES-128-GCM 加密 payload，附 auth 密钥派生）后 POST 到 endpoint；投递段——推送服务（FCM/APNs 等）校验签名（JWT 中的 VAPID 公钥）与订阅有效性，投递到设备；消费段——SW push 事件中浏览器自动完成 payload 解密（pushMessage 事件数据，加密信息在浏览器内解密后交给 SW），SW 展示通知或处理静默数据。工程要点：JWT 防重放（exp 短时）、payload 上限（4KB 左右，大内容用 data URL/消息引用）、推送服务限流与错误码（410 订阅失效）；私钥管理（服务端密钥库）。理解该链路是排查"推送收不到"的基础：分别验证签名、订阅有效性与投递日志。

回答按"四段链路 → RFC 机制（JWT 与 ECDH+AES-GCM）→ 工程要点与排障"组织，突出"浏览器解密"与"410 失效"两个排障关键点。

• 订阅的创建、取消与有效性
• pushsubscriptionchange 的触发场景
• 服务端订阅记录的同步与清理

订阅生命周期：subscribe 创建（需权限与 SW 就绪）→ 保存到服务端 → 推送期间可能失效（推送服务到期、应用重新注册、浏览器重置、VAPID 密钥轮换）→ unsubscribe 取消（用户关闭通知或主动注销）。pushsubscriptionchange 在"订阅失效但浏览器可以重新订阅"时触发（SW 内监听）：场景包括推送服务过期续订、浏览器服务迁移、安全密钥更新；处理流程：在事件里重新 pushManager.subscribe（复用原 options）获得新订阅，更新到服务端（替换旧记录），并把新订阅回传给页面（postMessage）更新前端状态。工程要点：服务端以订阅 endpoint 为键去重，变更时"旧删新增"原子更新；定期清理无效订阅（推送返回 410/404 时删除记录）；unsubscribe 后必须同步服务端（防继续推送）；订阅状态展示（开关）与用户意图一致（用户关闭系统通知权限时订阅可能仍存在但不可达，需检测 Notification.permission 联动）。把"订阅变更"视为数据同步问题，用事件驱动而非轮询。

回答按"生命周期阶段 → pushsubscriptionchange 机制 → 服务端同步与清理 → 状态一致性"组织，突出"订阅记录必须与服务端保持一致"。

• 两类同步的触发语义与适用场景
• 周期同步的注册约束（参与度、时间窗）
• 兼容现状与降级策略

差异在触发语义：一次性 Background Sync（navigator.sync.register）在网络恢复后尽快触发一次，适合"离线操作重放、单次提交"；Periodic Background Sync（navigator.periodicSync.register）按间隔（如每日）在"条件允许"时触发，适合"定期刷新内容、预取数据"，且是"尽力而为"——浏览器决定实际触发时机。周期同步的注册条件：必须已安装 PWA、站点有足够参与度（engagement）、用户授权（Chrome 需用户确认）、间隔受浏览器限制（Chrome 最小间隔约 12 小时，且与站点参与度挂钩），不满足时 register 拒绝或事件不触发。兼容现状：一次性同步 Chrome/Edge 支持较好，Safari 长期不支持（iOS 需降级为"联网后主动拉取"）；周期同步仅 Chrome 系支持且策略严格。工程策略：核心同步路径用一次性同步 + 运行时补拉（app 启动、联网事件）；周期同步仅作增强（预取资讯等），并检测支持性（'periodicSync' in registration）决定是否启用。

回答按"语义差异 → 注册条件（参与度/授权/间隔）→ 兼容矩阵 → 降级策略"组织，突出周期同步的"尽力而为"本质。

• 冲突来源（多端并发、离线覆盖）
• 冲突策略（LWW、版本向量、合并）
• 离线读（缓存优先）与写（队列）策略

冲突根源是"同一数据的多个版本在不同端产生"，常见策略：LWW（Last-Write-Wins）——时间戳/序号取新，简单但时钟不可靠时误覆盖；版本向量/修订号——每次更新递增版本，服务端比对版本拒绝过期写入（409 时客户端重拉合并）；字段级合并——可合并的实体（如笔记、清单）做字段级三向合并，配合操作日志（CRDT 或操作列表）重放；业务规则裁决——按业务语义（报价单以金额为准、库存以服务端为准）指定仲裁方。离线读写策略：读——缓存优先（离线直接读缓存）与"先缓存后网络更新"（stale-while-revalidate）组合，写——离线写入本地队列（IndexedDB），联网后批量重放（Background Sync），重放需幂等（客户端生成操作 id，服务端去重）。工程要点：每条数据带"最后修改时间+修改者"元数据；冲突上报给用户确认（仅当自动策略不安全时）；同步失败保留队列不丢数据。把同步层设计为"可重放、可仲裁、可观测"。

回答按"冲突来源 → 四类策略 → 离线读写策略 → 幂等与元数据治理"组织，核心是"版本元数据 + 幂等重放 + 明确仲裁方"。

• push 事件内 showNotification 的调用
• notificationclick 的响应与导航
• 多窗口场景的聚焦策略

push 事件处理：解析推送数据（data 字段携带消息与目标 URL）→ 用 registration.showNotification(title, options) 展示（options 含 body、icon、badge、data、actions、tag 等）→ 调用 event.waitUntil 保证展示完成（推送服务会重试直到处理完成）。点击处理：notificationclick 事件中 event.notification.close() 关闭通知，读取 notification.data 中的目标 URL，再导航：优先用 clients.matchAll({type: 'window', includeUncontrolled: true}) 查找已打开的窗口——命中则 focus 并 navigate 到目标页（postMessage 告知路由），未命中则 clients.openWindow(url) 新开；行动作按钮（actions）按 action 值区分导航目标。工程要点：通知必须"有内容"（userVisibleOnly 约束下无通知的静默推送受限）；data 只放轻量元数据（放不下或敏感的内容服务端存、通知只带 id 拉取）；多窗口时避免重复开窗（用 windowClient.focus + 导航）；点击统计（转化漏斗：送达→点击→打开）。

回答按"push 展示 → click 导航（聚焦/新开）→ data 轻量化与统计"组织，突出"先找已开窗口再开新窗"的标准实践。

• 权限弹窗的"一次性"特性
• 两步确认（预授权引导）模式
• 时机选择与数据驱动

浏览器权限弹窗是"一次性且不可重来"（拒绝后难再触发，只能用户手动改设置），因此"何时申请"直接决定转化率：在首次访问或与业务无关的时刻弹窗，拒绝率与误触率高；在"用户刚完成有价值动作、正需要通知"的时机申请（如订阅成功、订单创建、聊天会话加入），接受率显著提升。pre-permission prompt（两步确认）模式：不直接调原生弹窗，先在页面内展示自定义引导（说明通知价值与用途，含"允许/暂不"），用户确认后再触发系统权限弹窗——好处：被系统弹窗"吓退"的用户被前置引导过滤，进入系统弹窗的都是有意向者，转化率提升且负反馈少（暂不≠永久拒绝）；配合渐进式（多时机多次尝试：首次拒绝后可在他处再引导，但需尊重用户）。工程化：埋点漏斗（引导展示→同意→授权→订阅成功），A/B 测时机与文案；拒绝后降级方案（站内提醒、邮件）；合规上说明用途（权限文案、隐私政策）。"两步确认 + 时机数据化"是现代 Push 转化的标准实践。

回答按"一次性弹窗特性 → 时机策略 → 两步确认机制 → 数据驱动迭代"组织，核心是"把系统弹窗留给有意向用户"。

• 需添加到主屏幕且独立模式的硬性条件
• 订阅流程与权限交互的差异
• 非安装态用户的降级策略

iOS Safari 16.4+ 支持 Web Push 但有硬性限制：用户必须"添加到主屏幕"（安装为 PWA）且在 standalone 模式（独立窗口）启动后，站点才能申请通知权限与订阅推送；普通浏览器标签页中的站点无法使用 Push。适配策略：能力检测与引导——判断 display-mode: standalone 与是否存在安装（matchMedia），未安装用户在应用内提供"添加到主屏幕"分步引导（iOS 无法用 beforeinstallprompt 自动化，需人工指引）；安装后首次启动时再申请权限与订阅（遵循"先引导安装、待用户主动使用后再请求"的时机策略，避免过早打扰）；iOS 的权限交互是"允许/不允许"且设置入口在系统设置，需提示用户路径；订阅管理与 pushsubscriptionchange 同标准；已知差异：iOS 推送到达依赖系统通知中心、无角标部分行为差异（用 Badging API 兼容处理）、静默推送受限（userVisibleOnly 约束同样适用）。降级：非安装态用户提供站内通知中心/邮件替代；数据看板区分 iOS 安装用户与网页用户的推送覆盖。

回答按"硬性限制清单 → 引导与时机适配 → 差异处理 → 降级方案"组织，核心是"先引导安装、再申请推送"的漏斗设计。

• payload 大小上限与内容策略
• data-only push 的投递与事件处理
• 后台任务能力边界与滥用风险

payload 大小限制：推送服务对 payload 有上限（Chrome/FCM 约 4KB，多字节 UTF-8 按字节计），超限投递失败；工程策略：payload 只放轻量元数据（标题、摘要、id、目标 URL），正文内容服务端存储，SW 在 push 事件里按 id 拉取（或直接用 URL 跳转），避免把大内容塞 payload。data-only（静默）推送：payload 不带可见通知（userVisibleOnly 约束下仍需在事件中展示通知或做数据任务——"静默"指不弹通知的受限形态，实际浏览器会限制无通知的推送展示频率，滥用会被治理）；可在 push 事件中做数据预取、缓存更新等后台任务，但浏览器限制执行时长与频率，且 iOS 对无通知推送更严。取舍：需要"内容新鲜"用通知+payload 拉取；需要"后台静默刷新"优先用周期同步/运行时拉取，data-only 推送仅作补充唤醒；必须遵守"每条推送对应可见通知"的平台规则，否则订阅被降权。工程上把推送当"信号"而非"数据通道"。

回答按"payload 上限与内容策略 → data-only 机制与限制 → 后台任务取舍 → 合规"组织，核心是"推送传信号、数据走接口"。

• setAppBadge/clearAppBadge 的机制
• 角标的应用场景（未读数、任务状态）
• 平台差异与权限

Badging API 让已安装的 PWA 更新应用图标角标：navigator.setAppBadge(count) 设置数字角标（无参为纯点），clearAppBadge() 清除；在安装（standalone）场景生效——桌面端任务栏/Dock 与移动端主屏图标显示。工程应用：未读消息数、待办任务数、下载/同步进度状态、通知聚合。实现要点：角标数据源统一（SW 与页面都更新时用同一计算逻辑，避免覆盖）；推送到达时在 push 事件里同步 setAppBadge（后台也能更新）；页面可见与阅读时清除（read 事件）；平台差异：Chrome 桌面/Android 支持（需安装），macOS 依赖系统权限（Dock 角标，部分版本需通知权限），iOS 支持有限（需安装且随系统版本），不支持平台需降级（自定义 UI 内角标）；频繁更新注意节流；setAppBadge 在不可见时受限（后台由 SW 更新）。价值：把"原生级信息密度"带到 PWA（信息无需打开应用即可感知）。

回答按"API 机制 → 场景 → 同步与清除逻辑 → 平台差异与降级"组织，突出"数据源统一 + 后台更新"两点。

• 离线优先的架构分层（壳/数据/操作）
• SWR 策略的机制与适用资源
• 大型 SPA 的版本与一致性治理

大型 SPA 离线优先分三层：壳层（HTML/CSS/JS）用 CacheFirst/预缓存保证离线可启动；数据层（API 响应）用 stale-while-revalidate——先返回缓存数据（立即渲染），后台请求网络更新缓存（下次更快），页面用"数据版本 + 刷新指示"呈现新数据；操作层（写操作）入离线队列后台同步。SWR 的工程价值：弱网/离线不空白（有数据即展示）、首屏加速（缓存直出）、体验平滑（无加载态闪烁）；代价是数据可能短暂过期，需新鲜度标记与 UI 提示（"数据更新于 x 分钟前"）。大型 SPA 治理要点：缓存命名空间与版本化（发布后旧缓存失效）；API 缓存按查询键（URL+参数）与业务语义（非敏感、可缓存）声明，敏感数据不入缓存；多标签页一致性（BroadcastChannel 通知刷新）；SWR 的请求合并（并发请求去重）；离线队列幂等与冲突。价值本质：把"网络可用性"从架构假设变成"能力增强"，用户体验从"不可用"变为"降级可用"。

回答按"三层离线架构 → SWR 机制与收益 → 版本/安全/一致性治理"组织，突出"分层策略 + 版本化"的落地方法。

• 指标采集（SW/页面/缓存命中率）
• 错误与崩溃的检测上报
• 恢复机制（自愈、降级、重建缓存）

PWA 可观测性覆盖三层：页面层——首屏性能（FCP/LCP/TTI）、JS 错误与资源加载失败（window.onerror、unhandledrejection、performance entries）；SW 层——install/activate 失败率、fetch 命中率（cache 命中/网络回源）、缓存清理异常、同步任务成功率；推送层——送达率、点击率、订阅有效期分布。采集通道：页面指标常规埋点上报；SW 内指标经 postMessage 转发页面或直接 fetch 上报（注意 SW 与页面上报去重）；崩溃恢复：SW 挂掉（浏览器回收）不可直接感知，用"页面心跳 + 定时器检测"发现 SW 缺失后重新注册；缓存损坏（版本不匹配、清单失效）用版本化命名 + activate 清理 + 失败自动重建（清空旧命名空间重新预缓存）；页面崩溃用 beforeunload 状态标记 + 重启后提示恢复（历史状态存 IndexedDB）；错误分级告警（错误率、崩溃率阈值）与灰度观察（新版本发布对比指标）形成闭环。价值：离线/缓存类问题"看不见摸不着"，可观测性是唯一排障入口。

回答按"三层指标 → 采集通道 → 崩溃自愈机制 → 告警与灰度闭环"组织，突出"SW 指标上报"与"缓存自动重建"两个专项。

• 游标的分页与批量遍历
• 事务的原子性与写入模式
• 离线队列与缓存数据的组织

游标（cursor）用于大数据集的顺序遍历与分页：离线优先架构中"本地数据列表"（消息、记录、缓存条目）常以游标分页加载（每页 N 条、按索引排序），避免一次性取全量导致内存与渲染压力；游标配合索引做范围查询（按时间、状态过滤）。事务保障写入原子性：批量写（同步队列重放、缓存清理）用单个 readwrite 事务包裹，中途失败整体回滚，保证数据一致性；离线队列的"写入+出队删除"在事务内完成，避免丢失或重复。工程要点：事务内不做异步等待（事件循环自动提交，跨事务异步操作导致状态错乱）；长事务有时长限制（大事务分片提交）；读写分离（读用 readonly 事务并行，写串行）；离线数据模型按"查询模式"设计索引（索引不是越多越好，写放大）；迁移（onupgradeneeded）与版本管理保证结构演进；游标遍历大集合时用 IDBRequest 的 continue 控制节奏（分片+requestAnimationFrame）避免阻塞 UI。

回答按"游标分页 → 事务原子性 → 队列与索引设计 → 迁移与性能"组织，突出"事务内无异步"与"索引按查询设计"两个要点。

• 订阅记录与用户身份的绑定
• 多设备/多浏览器的订阅管理
• 失效订阅的检测与清理流程

订阅状态同步的关键是"订阅记录与用户身份绑定"：登录后把 PushSubscription 以用户 id 为键上报服务端（upsert），一个用户可关联多设备/多浏览器的多条订阅记录；退出登录/注销时按会话删除对应记录；前端把"订阅开关"状态与服务端记录保持一致（开启→确保记录存在，关闭→删除记录）。多端同步：同一账号在不同设备各自订阅，服务端记录集合管理，推送时按设备过滤（用户设置偏好：哪些设备收推送）；订阅变更（pushsubscriptionchange）更新对应记录；登录态变化（token 过期）清理关联记录。失效订阅清理：推送返回 410/404（Gone/Not Found）标记该 endpoint 失效，服务端定期批量清理；订阅健康度检查（发送测试推送验证到达）；统计失效率发现"权限被用户关闭"的设备，提示重新授权或移除。工程要点：订阅操作幂等（同一订阅重复上报不重复）；记录带时间戳便于审计；清理任务离线执行（定时器）不影响主流程。

回答按"身份绑定模型 → 多端同步流程 → 失效检测与清理 → 幂等与运维"组织，核心是"订阅是用户资产的端级记录"。

• sync 事件的触发条件（联网后）
• 失败重试的退避与上限
• 与网络状态监测的组合策略

Background Sync 的核心机制是"事件与网络状态绑定"：应用注册 sync 任务后，浏览器在"网络恢复可用"时触发 SW 的 sync 事件（离线期间排队、联网后尽快执行），开发者无需自建网络监听（online/offline 事件只在页面层可用且不可靠）。重试机制：sync 事件处理中如果同步失败（请求失败、服务端错误），可以在事件内重新注册同名任务（重新排队），浏览器在后续网络条件允许时再次触发；浏览器对失败的次数与频率有隐式限制（过多失败会退避/停止），需合理设计重试次数与降级（超过上限提示用户或转后台定期重试）。协作策略：sync 事件内先探测关键资源可达性（fetch 探活或直接尝试），区分"网络不可用"（重排队）与"服务端错误"（记录错误、有限重试）；配合页面可见时的主动刷新兜底（离线写入的队列在用户回到前台时立即尝试）；队列重放顺序（按时间/优先级）与幂等（操作 id）保证不重复提交。工程要点：注册 tag 唯一且可去重（同 tag 合并）；事件处理时间有限（超时被终止，任务分片）；观测同步成功率与队列深度。

回答按"触发机制（联网触发）→ 重试与退避 → 与网络监测/前台刷新的组合 → 幂等与观测"组织，突出"依赖浏览器触发而非自建监听"。