题干与适用场景
一个管理后台允许用户同时打开多个标签页。用户在一个标签页登出、切换主题或更新通知后，其他标签页应尽快反映变化；刷新、休眠、重复消息和不支持 BroadcastChannel 的浏览器不能破坏最终状态。请设计同步协议、恢复策略、降级方案和验证指标。
这是面向前端、Web 平台和前端系统设计岗位的浏览器协作题。标签页数量、同步时延和事件类型是面试假设，不是浏览器保证。重点是理解 BroadcastChannel 的同源/存储分区边界、消息不持久化的后果、状态与事件的取舍，以及 localStorage、IndexedDB、SharedWorker 或 Web Locks 的组合条件。
面试官考察点
第一，能否说清 API 的边界。BroadcastChannel 让同一 origin 且处于可通信 storage partition 的窗口、标签页、iframe 和 worker 互发消息；它不是跨域通道、持久队列或分布式一致性服务。
第二，能否设计幂等协议。消息可能重复、发送者收不到自己的广播、接收页面可能刚好关闭或睡眠；只传“主题变了”而没有版本和重新读取路径，会留下永久陈旧状态。
第三，能否区分事件通知和状态来源。登出可广播失效提示，主题可广播后写入持久化设置，通知列表应让接收者重新读取权威缓存，而不是把整份列表当作真相。
最后，能否处理生命周期与降级：关闭 channel、避免把令牌放入消息、检测能力、使用 storage 事件或服务器重新拉取，并用可观测指标证明同步没有制造循环和内存泄漏。
回答前需要澄清的问题
- 要同步的是一次性事件、当前状态还是可重放历史？这决定是否需要持久化版本。
- 通信范围是同一 origin、同一顶层站点下的 iframe，还是跨子域？storage partition 可能让“同源”仍无法互通。
- 丢失一条消息是否可接受？登出、权限撤销与编辑冲突的恢复要求不同。
- 状态真相在哪里：服务器、IndexedDB、localStorage、内存缓存还是 Service Worker？
- 是否需要保证只有一个标签页执行刷新、同步或写入？若需要，广播本身不提供锁。
- 浏览器兼容矩阵、私密模式、后台冻结和多窗口数量是多少？
- 消息是否可能包含个人资料、权限或令牌？若包含，应改为无敏感内容的失效通知。
30 秒回答框架
“我会把 BroadcastChannel 当作低延迟通知总线，不当作持久状态源。每条消息带协议版本、事件类型、单调序列或状态版本和 trace ID；接收者先校验来源与结构，再按事件幂等处理，发现版本跳跃就从 localStorage、IndexedDB 或服务器重新读取。登出只发送失效信号，主题写入持久化设置，通知变化触发重新拉取。能力检测失败时降级到 storage 事件或定期拉取；需要单写者时使用 Web Locks 或服务器协调。所有 channel 在卸载时关闭，并用指标验证延迟、丢失恢复和重复处理。”
分步骤深入解答
第一步：定义消息与权威状态
为每个功能设定状态来源。主题和语言是用户偏好，可由持久化设置保存；通知列表和权限应由服务器或本地缓存重新读取；登出是会话失效信号，不能把 access token 放进消息。广播只携带无敏感的 type、version、entityKey、updatedAt 或 traceId。
MDN 说明 BroadcastChannel 允许同源浏览上下文和 worker 双向通信，但消息协议由应用自行定义，没有自动协商。协议版本、未知事件处理和字段校验必须由前端明确约定。
第二步：处理重复、乱序与丢失
每个状态域维护最后处理版本。接收消息时，版本小于或等于本地版本直接忽略；版本相邻可触发一次读取；出现跳跃则标记 gap 并从权威来源重新同步。若业务只能提供事件而没有版本，至少使用去重 ID 和短期已处理集合，但它无法证明中间事件没有丢失。
不要假设广播可靠送达。发送者不会收到自己的消息，刚打开或已休眠的标签页可能错过事件。因此页面启动时必须先读取持久化状态或服务器快照，再订阅 channel；消息只是缩短新鲜度延迟。
第三步：选择持久化和协调组合
localStorage 适合小型偏好和触发 storage 事件；它不是高吞吐数据库，也不适合存放令牌。IndexedDB 适合较大本地缓存和版本化快照。Service Worker 可以作为后台同步参与者，但它也应把结果写入可恢复存储。
BroadcastChannel 解决“通知多个上下文”；它不保证单写者。若只有一个标签页可以刷新缓存、执行迁移或提交批处理，使用 Web Locks；若锁不可用，就让操作带版本条件并在服务器端裁决。SharedWorker 适合共享连接或集中状态，但增加生命周期和兼容复杂度。
第四步：实现安全的接收和降级
创建 channel 后只接受白名单事件，限制消息大小，拒绝未知版本和不符合 schema 的对象。消息中不放 access token、完整用户资料或可直接执行的 HTML。对登出事件立即清除本地敏感缓存并导航到登录页；对主题事件更新 UI，但仍以持久化值为准。
能力检测失败时优先使用 storage 事件同步小型状态；若浏览器或分区仍不支持，再采用窗口聚焦时重新拉取、短轮询或服务器推送。降级策略必须允许重复执行，不能让“没有广播”变成永久不同步。
第五步：管理资源与验证指标
组件或页面销毁时移除监听器并调用 close()；不要每次渲染都创建新 channel。统一命名空间，避免不同应用误订阅同名频道。给消息增加来源标签和 trace ID，防止一个标签页收到后再次广播造成循环。
验证至少覆盖：多标签页端到端延迟、重复/乱序、休眠后恢复、刷新初始快照、storage 降级、storage partition 隔离、channel 关闭、异常大消息、消息循环和多用户切换。指标包括事件处理成功率、版本 gap 次数、重新拉取次数、重复丢弃率、恢复耗时和未关闭 channel 数量。
高质量示范回答
“我会先把 BroadcastChannel 定义为通知总线，不把它当作队列。登出事件只带会话失效类型和版本；主题事件写入 localStorage 后广播新的设置版本；通知列表只广播实体键和版本，接收标签页重新从服务器或 IndexedDB 读取。消息不含令牌和完整用户数据。
每个消息有协议版本、单调状态版本和 trace ID。接收者拒绝未知结构，已处理或更旧版本直接丢弃，发现版本跳跃就重新拉取快照。页面启动先加载快照再订阅，因为刚打开或休眠的标签页可能错过广播，发送者也收不到自己的消息。
如果需要单写者刷新缓存，我会加 Web Locks；仅靠 BroadcastChannel 不能防止两个标签页同时写入。能力不支持时，小型偏好降级到 storage 事件，其他数据在聚焦或短轮询时重新读取。组件销毁要移除监听并关闭 channel，指标观察延迟、gap、重复、恢复时间和未关闭资源。这样把低延迟通知、可恢复状态和浏览器兼容性分别处理。”
常见错误
- 把广播当持久队列 → 新开或休眠标签页会漏事件 → 启动先读快照，消息只做增量提示。
- 消息直接携带 token 或完整状态 → 扩大敏感数据暴露和版本冲突 → 只传无敏感事件、键和版本。
- 没有版本或去重 ID → 重复、乱序会回退 UI → 单调版本、幂等处理和 gap 重读。
- 把同源等同于必然互通 → storage partition 可能隔离上下文 → 验证实际通信范围并准备降级。
- 用 BroadcastChannel 实现锁 → 两个标签页仍可能同时写入 → 使用 Web Locks 或服务器条件写。
- 每次渲染创建 channel → 监听器和资源泄漏 → 稳定实例、卸载时移除并 close。
- 接收后无条件再广播 → 形成消息回环 → 保留来源/trace ID，只由状态变化触发发送。
- 把 storage 事件当完整替代品 → 它只覆盖部分写入场景且不传给同一窗口 → 定义能力差异并补充重新拉取。
追问及应对
追问一：用户在两个标签页同时编辑同一表单，如何避免覆盖？
广播只通知“资源版本变了”，不直接覆盖本地草稿。提交时带基线版本，服务器用条件写拒绝过期版本；前端展示冲突并让用户合并。若只是本地偏好，可用 Web Locks 串行写入。
追问二：一个标签页休眠 20 分钟后恢复，如何追上状态？
恢复时重新读取服务器或 IndexedDB 快照，比较状态版本后再处理增量。不要依赖缓存的最后一条广播；若快照不可用，标记需要重新认证或展示明确的过期状态。
追问三：不同子域名的页面需要互通，BroadcastChannel 能解决吗？
不能直接假设可以。BroadcastChannel 受同源和 storage partition 限制；跨源通信需要明确的 postMessage 窗口关系或服务器协调，并验证 origin、消息 schema 和权限，不能通过放宽安全边界来“共享频道”。
追问四：需要保证只有一个标签页维护 WebSocket，如何设计？
BroadcastChannel 可传播连接状态和数据，但不提供选主。优先用 Web Locks 选持有者，其他标签页订阅广播；持有者关闭或失去锁后重新选主。若浏览器能力不足，采用服务器租约或允许多个连接并用服务端去重，明确成本取舍。