BroadcastChannel需严格对齐生命周期、频道名和环境限制：频道名须全小写+下划线且逐字符一致；发送前检查bc有效性；SSR需hydration后创建；必须监听onmessageerror；HTTPS为必需，后台标签页可能丢消息。
BroadcastChannel 不是“能用就行”的 API，它在同源页面间通信时看似简单，但稍不注意就会消息发不出、收不到、或重复触发——根本原因不是代码写错，而是生命周期、频道名、环境限制没对齐。
频道名必须完全一致且区分大小写
哪怕多一个空格、大小写不匹配（'chat' 和 'Chat'），两个页面就属于不同频道，互不可见。浏览器不会报错，只是静默丢弃。
- 检查所有页面中
new BroadcastChannel('xxx')的字符串是否逐字符相同（建议全小写 + 下划线，如'auth_state'） - 避免从变量拼接频道名，比如
new BroadcastChannel(prefix + '_channel')，容易因环境差异导致不一致 - 频道名不能含 Unicode 控制字符或不可见空格，复制粘贴时尤其要小心
页面未 ready 就调用 postMessage 会失败
postMessage 不会抛异常，但若页面 DOM 或 JS 执行流还没走到 new BroadcastChannel() 这一步，消息就直接消失——不是延迟，是彻底丢失。
- 发送前务必确认
bc是有效实例：if (bc && !bc.closed) { bc.postMessage(...) } - 不要在模块顶层立即发消息；把发送逻辑放在事件回调（如按钮点击）、
DOMContentLoaded后，或封装成异步初始化函数 - 服务端渲染（SSR）场景下，需确保客户端 hydration 完成后再创建频道
必须单独监听 onmessageerror
当收到无法解析的 message（比如被恶意 iframe 注入的非法数据、JSON 格式错误、跨域脚本污染），onmessage 不会触发，也不会报错——除非你显式监听了 onmessageerror。
立即学习“前端免费学习笔记（深入）”；
- 漏掉这句，等于放弃所有异常路径的可观测性：
bc.onmessageerror = e => console.error('BroadcastChannel parse error:', e) - 常见于开发时混用不同版本的数据结构（如旧页面发字符串，新页面 expect 对象），或测试时手动
postMessage({})传了 null - 生产环境建议加基础校验：在
onmessage里先if (typeof event.data !== 'object') return
HTTPS 环境限制和页面休眠影响
Chrome 90+ 在非安全上下文（http:// 除 localhost 外）默认禁用 BroadcastChannel；而标签页后台冻结时，消息可能被浏览器直接丢弃，不排队也不重试。
- 本地开发用
http://localhost没问题，但测试服/预发服必须上 HTTPS，否则new BroadcastChannel()会返回null - 不要依赖 BroadcastChannel 做关键状态同步（如登出强同步）；它适合“尽力而为”的场景，重要操作仍需后端兜底或配合
localStorage+storage事件降级 - Chrome 后台标签页休眠后，
onmessage可能延迟数秒甚至不触发；若需可靠通知，考虑 Service Worker + push API 组合
真正难的不是写那三行 new BroadcastChannel、postMessage、onmessage，而是让所有页面在正确时机、用完全一致的频道名、在安全上下文中、带着容错意识去跑通整条链路——任何一个环节松动，消息就断在看不见的地方。
