BroadcastChannel能用但需同源、频道名逐字符一致且页面已加载完成；90%的通信失败源于频道名大小写/空格不一致或DOMContentLoaded前调用postMessage，必须监听onmessageerror并确保HTTPS环境。
BroadcastChannel 能用，但必须同源、频道名逐字符一致、页面已加载完成——发不出或收不到消息，90% 是频道名大小写/空格不一致，或在 DOMContentLoaded 前就调用了 postMessage()。
频道名必须完全一致（区分大小写+无空格）
浏览器对频道名不做任何标准化处理：'auth' 和 'Auth' 是两个互不通信的频道；'theme '（末尾有空格） ≠ 'theme'。静默失败，不报错。
- 所有页面统一用常量定义频道名，例如
const CHANNEL_NAME = 'ui-theme'; - 避免拼接：不要写
new BroadcastChannel(prefix + '-config')，环境差异易导致不一致 - 复制粘贴频道名时，用
.trim()防不可见字符：new BroadcastChannel(name.trim())
发送前必须确认实例有效且页面已就绪
postMessage() 不会抛错，但若目标页还没执行 new BroadcastChannel()，消息就彻底丢失——不缓存、不重试、不通知。
- 不要在
<script>标签顶部立即发消息，尤其脚本放在<head>中 - 发送前加校验：
if (bc && !bc.closed) { bc.postMessage(data); } - SPA 路由切换或 HMR 热更新时，容易重复创建实例，建议封装单例：
const bc = window.bc ?? (window.bc = new BroadcastChannel('auth'))
必须显式监听 onmessageerror
当收到非法 JSON（如被恶意 iframe 注入、旧版数据结构不兼容、手动传了 null 或函数）时，onmessage 完全不会触发，错误被吞掉。
立即学习“前端免费学习笔记（深入）”；
- 漏掉这句，等于放弃所有异常路径的可观测性：
bc.onmessageerror = e => console.warn('BroadcastChannel parse error:', e) - 开发时混用不同版本的数据格式（比如一个页面发字符串，另一个 expect 对象）是常见原因
- 生产环境建议在
onmessage里先做基础类型检查：if (typeof event.data !== 'object' || !event.data.type) return
HTTPS 是硬性前提，后台标签页可能丢消息
Chrome 90+ 在非安全上下文（http:// 除 localhost 外）直接禁用 BroadcastChannel；而标签页进入后台冻结状态（如 Chrome 自动休眠）时，消息可能被浏览器丢弃，不排队也不重试。
- 本地开发用
http://localhost没问题，但测试服/预发服必须上 HTTPS，否则new BroadcastChannel()可能返回null - 不要依赖它做关键强同步（如登出后立刻清空 token），需配合
localStorage+storage事件兜底 - Safari 隐私模式下可能禁用该 API，可提前检测：
if (typeof BroadcastChannel === 'undefined') { /* 降级 */ }
实际使用中，最易被忽略的是频道名一致性与 onmessageerror 的缺失——前者让调试像在黑盒里找针，后者让非法消息变成幽灵错误。
