BroadcastChannel：同源消息与隐私边界
使用 BroadcastChannel 协调同源浏览器上下文，同时保留关闭、重载、回退和隐私边界。
BotBrowser Team
BroadcastChannel 适合让同源的标签页、窗口、worker 或框架交换短通知。它不是通用消息总线、认证信号，也不是两个上下文属于同一人的证明。消息投递受浏览器来源模型约束，缺失或延迟消息有许多正常原因。BotBrowser 支持重复授权的同源夹具并记录可见的投递、关闭和重开结果，但不能跨源投递、放宽同源策略或保证不同浏览器版本的时序。
TL;DR
- 使用 BroadcastChannel 协调同源上下文。
- 组件结束时关闭通道，把重载、挂起和终止视为正常生命周期状态。
- 先做能力检测；API 不可用时保留
storage、worker 或服务端刷新等回退。 - 同源可达性不是认证、身份、位置或信任证据。
- BotBrowser 可以重复授权夹具和比较可见结果，但不能跨源或保证时序。
Contents
BroadcastChannel 传递什么
new BroadcastChannel(name) 为当前来源和上下文组创建命名通道。postMessage() 使用 structured clone 把消息交给同名的其他可用上下文，发送者不会收到自己的消息。它不是持久队列，也不提供投递回执。
使用稳定名称和短消息数据，例如 {version: 3, type: 'cart-changed', key: 'cart'}。不要放入令牌、完整账户记录或私密文本。通道应提示应用重新读取权威状态，而不是替代事务。先写入权威变更，再发布通知；组件卸载时移除 listener 并调用 close()。
消息是尽力投递的。上下文可能关闭、冻结或在发送后才创建；不可结构化克隆的值也会失败。处理器应比较版本、容忍重复和过期事件，再更新界面。
来源与隐私边界
浏览器比较协议、主机和端口。不同子域或端口即使属于同一团队也不共享通道。sandbox 框架可能获得不透明来源，存储分区和隐私窗口也可能改变可达性。
同源投递不建立身份。缺失消息不等于隔离失败，应检查来源、名称、监听时机、生命周期和可克隆性。参考 WHATWG web messaging、MDN BroadcastChannel 和 MDN 同源策略。
不要把通道名称和消息数据连接到账户、支付或精确位置记录。draft-updated 只表示产品状态可能变化，不表示谁输入、身处何地或哪个设备权威。W3C 隐私原则支持目的限制和数据最小化。
生命周期与回退设计
先设计没有 API 也能工作的基线。检测 BroadcastChannel，只在需要时创建；创建失败时仍保持主页面可用。storage、共享 worker 和服务端刷新各有不同语义，应分别记录保障范围。
路由变化时关闭旧通道；重载后先读取当前状态，再等待通知；从隐藏状态返回时，如数据重要则刷新。让处理器幂等，限制队列并保留可见重试。测试 API 缺失、错误名称、错误来源、发送前关闭、晚注册接收者、clone 错误、挂起和 worker 终止。
使用 BotBrowser 测试
BotBrowser 支持运行授权的同源多上下文夹具，记录可见消息投递与关闭或重开结果，并比较声明的浏览器版本。它不能跨来源投递、绕过同源策略、保证不同版本的时序，也不能把通道可达性当作身份证据。测试使用合成数据，只记录浏览器版本、测试来源、监听状态、可见结果和回退结果。
结论
BroadcastChannel 是同源上下文之间的协调提示。把权威状态放在经过验证的存储中，在生命周期切换时关闭通道，让处理器幂等，并提供一等回退路径。BotBrowser 让授权比较可重复，而来源策略、应用授权、生命周期和隐私仍由相应系统负责。