4.1 高级API与扩展功能

4.1 高级 API 与扩展功能

本节摘要：高级接口的价值不在功能本身，而在它们重构了 Web 与操作系统之间的契约关系——从被动响应者升格为可信赖的系统参与者。本节讲后台同步的调度原理、推送与角标的协同哲学、文件与联系人接口的主权委托模型，以及事件驱动的分层状态机架构。（素材映射：原 4.1 节全部内容。）

读前必看

阅读完本节，你应当能够：

1. 解释后台同步的"至少一次执行"保证及其调度机制；
2. 设计按紧急度分层的通知策略；
3. 用声明式文件关联把应用变成系统级文件处理器；
4. 用分层状态机组织多接口协同的复杂业务。

一、从一个真实断点说起

拿一个具体业务来对照三种技术路线。货车还有半小时进仓库，调度员要提前收到提醒并把电子运单拉到本地。用传统网页做，等于让他不停手刷页面，或者跑一个费电又经常漏事的轮询循环；原生应用有后台任务和系统推送，天然胜任；而 PWA 如果只靠 Worker 里的请求拦截事件，这件事根本办不成——拦截事件只有在页面发出网络请求时才会被触发，可调度员这会儿什么请求都没发。

后台同步与周期同步这两个接口，就是专为补上这类断点而生的。把它们理解成"另一种定时器"会严重低估其意义：真正的机制是，页面先向浏览器登记一条意图——"等网络可用时替我跑完这段同步逻辑"，之后浏览器会替它挑选系统层面合算的执行窗口，比如无线网连上、设备插着电、处理器不忙的时候，并且承诺这段逻辑至少完整跑成一次。哪怕标签页早就关了、设备中途重启过，承诺依然有效。

这类保证之所以给得出来，靠的是浏览器与操作系统各出一层力。安卓上的 Chromium 把任务交给系统调度器排期；iOS 的 Safari 走的是受限的后台刷新通道；Firefox 则排自己的后台任务队列。串起来看是四段接力：页面把同步任务登记给 Worker，Worker 把意图上报给浏览器内核，内核再翻译成操作系统的调度调用，系统选中时机后沿原路把事件送回来触发执行。调度策略里明确写入了省电考量——不会为了同步天气数据在深夜把设备叫醒，却会把积压的任务攒到清晨充电时一并处理。

到这里可以点出本节的第一个核心命题了：**这些接口的分量不在"多了几个功能"，而在改写了 Web 与操作系统的关系——页面不再只是等着被点击的一方，而成了系统愿意托付任务的参与方。**桌面固定、主屏图标乃至将来可能出现的系统设置入口，都以这份信任为前提。

二、推送与角标：一体两面

后台同步管好了"数据什么时候更新"；"用户什么时候知道更新了"这件事，则由推送和角标一起负责。这两个接口经常被混为一谈，实际分工泾渭分明：推送负责把信息主动送到设备上，角标负责在图标上长期挂着记号。

先纠正一个普遍误解：推送接口并不天然等于弹通知。它的本体是一条加了密的下行通道，收件方甚至不需要页面正开着。服务器把消息发给浏览器厂商的推送服务，推送服务送达设备后由内核解开再转给对应 Worker 的推送事件处理器——到了这一步，要不要弹通知、要不要悄悄更新数据、甚至要不要直接丢弃，全都由前端代码自己决定。

只靠通知触达是有明显漏洞的：用户可能压根没看到，可能嫌烦开了屏蔽，也可能正开着会议静音。角标接口恰好补上这个缺口——往应用图标上摞一个数字，既不打断人，又持续提醒"还有东西没处理"。实验数据支持这个判断：启用角标的 PWA，七日留存平均能多出两成以上。道理不难理解：通知是转瞬即逝的事件，角标却把提醒固化成了空间里的存在——用户扫一眼桌面，图标本身就是信息。

把两者组合起来用，才见产品功力。看一个医疗预约的场景：检验报告一生成，后端就发推送；Worker 收到后先按兵不动（免得打扰患者休息），第一步是解析报告的紧急程度——常规结果只在图标上记个数、把摘要存到本地；遇到危急值，才同时调用通知接口并配高优先级振动。整理成决策矩阵：低紧急度用静默更新加角标，中紧急度弹前台通知，高紧急度上通知、振动、声音三件套。正是这种按数据语义分级的响应能力，让 PWA 第一次在临床情境里站到了与原生应用同等的位置。

三、文件与联系人：从沙箱到主权委托

后台任务回答了"什么时候跑"；文件处理与联系人这两个接口瞄准的则是另一个老大难：**Web 怎样与用户的个人数据建立一条可信任的通道。**在它们出现之前，网页对文件系统只有被动的选择框可用，通讯录更是完全碰不到——编辑文档、扫描名片这类高频需求，只能把用户推向原生应用。

文件处理接口的关键突破是声明式文件关联：在清单里写清楚本应用能接住哪些类型的文件、从哪个入口进。

{
  "file_handlers": [{
    "action": "/editor",
    "accept": {
      "text/plain": [".txt", ".md"],
      "application/pdf": [".pdf"]
    }
  }]
}
​

用户在资源管理器里双击文件，操作系统就会直接拉起这个 PWA，并把文件句柄递进来。这个句柄的分量要看清：它是可以序列化保存、可以长期持有的引用，不是用完即弃的一坨数据。应用往后任何时候都能凭它读内容；申请到写权限后能实现名副其实的"另存为"；再配上持久存储申请，文件管理体验已经能追平本地编辑器。浏览器团队的实测给出了量化的佐证：接了文件处理的笔记类 PWA，单个文档的平均编辑时长接近过去的四倍——用户终于可以双击进沉浸编辑、退出时自动存回原处，跟用本地软件一个手感。

联系人接口走的是另一条路子，同样讲究。它不给全量读取，只提供渐进授权加按字段选择：

const props = ['name', 'email', 'tel'];
const selected = await navigator.contacts.select(props, { multiple: true });
// 仅返回用户明确勾选的联系人与字段
​

授权弹窗会把话说全——"将访问姓名、邮箱和电话"，而不是一句含糊的"访问通讯录"。更要紧的是，拿到的只是只读快照，不是一条连着实时数据库的通道——应用没法定期在后台盯联系人变动，功能与隐私就在这条边界上各得其所。

两个接口背后藏着同一个判断：**现代 Web 的安全思路，不该停留在"不许碰"，而应走向"怎么授"；不是把沙箱焊死，而是让用户把数据主权有条件地托付出去。**用户点下"用此应用打开"的那一刻，完成的不只是调用一个工具，而是把信任交给了一个可审计、可撤销、能按粒度控制的主体。

四、分层状态机：多接口协同的架构答案

单看每个接口只是一件工具，真正的威力在它们与既有技术栈咬合之后。拿"离线拍照、自动进云相册"这条链路拆开看：取景要靠相机接口给视频流；快门落下后，数据块被存储层写进本地数据库并生成唯一标识；后台层随即登记一条同步任务；同步成功，服务端回执通过推送回到设备；状态层同时在图标上标个角标提示查看；用户还可以长按照片，直接存进本地相册目录。链路上每个环节背后是不同的接口，把它们串起来的正是 Service Worker——它早就不止是网络代理，而是整个应用的事件总线加状态协调器。

从这套实践里沉淀出的模式，叫事件驱动的分层状态机：把应用状态拆成几个互不干扰的维度（网络通断、数据同步进度、用户授权情况），每个维度各自听某个接口的事件来变迁，Worker 负责跨维度汇总并触发副作用。以网络这个维度为例：

这么架构的收益是釜底抽薪式的：断网时任务自动排队，电量告急时同步自动挂起，用户拒绝授权时功能体面降级。行业报告给过一组数字：按这套模式组织的 PWA，错误率平均比传统写法低约三分之二，主动卸载率也降了四成。原因说穿了很简单——用户得到的体验不再是"网页崩了"，而是"它在替我把事情办完"。

⚠️ 常见坑：把高级接口当"默认可用"。周期同步在多数移动浏览器仍受限，文件处理在非 Chromium 系支持有限——每项能力都必须挂在第三章讲的能力探测分支下，不可用时语义降级而非报错。

💡 关键直觉：这些接口正在共同定义一把新标尺——应用可信度：时间承诺（需要时出现）、空间承诺（视野内存在）、数据承诺（守护用户数据）、系统承诺（像系统组件一样可靠）。四维全部达到生产级，应用就从"可用"跨入"可信"，用户对它的依赖将从临时工具升华为数字生活基础设施。

五、落地顺序与验收建议

这么多能力，先上哪个？给一个经过大量项目验证的优先级。第一位永远是后台同步：它直接守护"弱网下操作不丢失"，是用户感知最强的可靠性提升，且实现相对独立。验收标准写成可测的句子——"飞行模式下提交表单，联网后三十秒内服务端收到且仅收到一次"。第二位是推送加角标的组合：负责把用户拉回来。验收关注两个数：到达率（服务端发送到设备事件触发的比例）与点击后的转化路径完整性（点通知能否直达目标页面而非首页）。第三位才是文件处理、联系人这类深度集成能力：它们价值高但受众窄，等前两项稳定后再上。

每一项上线后都要盯一周的真实数据而非演示效果。演示环境网络优良、设备崭新，是能力的最佳状态；真实用户的低端机与弱网才会暴露重试风暴、权限被拒后的死循环、通知权限被系统折叠等问题。把"被拒绝后再次询问的间隔"设计成周级而非天级，是这类问题里最值得提前想清楚的一条。

本节速览

• 要点一：后台同步是系统级事件注册机制，核心保证是"至少一次执行"。
• 要点二：推送是加密下行信道，弹不弹通知由前端逻辑决定。
• 要点三：角标把瞬时通知转化为空间化存在提示，与推送组合成分层触达。
• 要点四：文件句柄是持久化引用，联系人返回只读快照——可控授权优于禁止访问。
• 要点五：事件驱动的分层状态机是多接口协同的架构答案，Worker 是事件总线。
• 要点六：高级接口的重心是兑现四类承诺，度量的是可信度而非功能数。

有了能力和承诺，下一节解决"如何又快又稳"：以用户感知为原点，重构性能的坐标系。