broadcastchannel 使用结构化克隆算法自动深拷贝数据，不支持手动浅拷贝；它确保跨上下文数据隔离与安全，推荐设计扁平、轻量、语义清晰的消息结构。
BroadcastChannel 本身不涉及“浅拷贝”或“深拷贝”的主动选择——它底层使用的是 结构化克隆算法（Structured Clone Algorithm），对大多数常见数据类型自动执行安全、深度的复制。也就是说，你传一个普通对象，接收到的不是引用，而是独立副本；你改它，不影响原对象。所以严格来说，你无法在 BroadcastChannel 中“手动做浅拷贝”来传递消息，也不该试图绕过它的默认行为。
为什么 BroadcastChannel 不支持用户控制“浅拷贝”
结构化克隆是浏览器强制执行的序列化机制，目的是确保跨上下文数据传递的安全性与隔离性。它天然排除了循环引用、函数、DOM 节点、Error 实例等不可克隆值，同时对 Object、Array、Date、RegExp、Map、Set、TypedArray 等都做完整深拷贝。这意味着：
- 你传
{ a: 1, b: { c: 2 } }，另一端收到的是全新对象，嵌套对象也已复制 - 你不能传
obj1并期望另一端修改obj1.b时影响你本地的obj1.b——根本不可能，因为压根没共享内存 - 没有类似
Object.assign({}, msg)或展开运算符这样的“浅层处理”必要，BroadcastChannel 已帮你做了更彻底的隔离
如果你只想传“轻量、扁平、无嵌套”的消息结构
这不是靠“浅拷贝”，而是靠 设计简洁的数据结构。这才是实际开发中真正可控、推荐的做法：
- 只用基础类型：字符串、数字、布尔、null、数组（含基本类型元素）、简单键值对对象（无方法、无 Date/RegExp/嵌套对象）
- 避免深层嵌套：例如把
{ user: { profile: { name: 'A' } } }改为{ userId: 123, userName: 'A', userTheme: 'dark' } - 需要传递复杂状态时，用 ID + 事件类型代替完整数据：
{ type: 'ITEM_UPDATED', id: 'abc123' }，让接收方自行查本地缓存或 store
哪些情况看起来像“浅拷贝需求”，其实有更好解法
常见误解场景及对应建议：
-
想节省序列化开销？——BroadcastChannel 对简单对象极快，性能瓶颈通常不在克隆，而在频繁发送或大体积 ArrayBuffer；如真需高效，可改用 Transferable（如
postMessage(data, [buffer])），但仅限 ArrayBuffer 及其视图，且发送后原 buffer 失效 -
想让多个标签页共用某个配置对象？——不该靠共享引用，而应统一由 localStorage / IndexedDB 持久化，用 BroadcastChannel 仅作“通知变更”信号，比如
{ type: 'CONFIG_REFRESHED' } -
接收到消息后想快速更新局部状态？——这是应用层逻辑，在
onmessage回调里用Object.assign(state, event.data)或解构赋值即可，和通信机制无关
本质上，BroadcastChannel 的设计哲学就是“消息即快照”，不是“引用共享”。你不需要、也不应该在它上面模拟浅拷贝——专注把消息设计得小、平、语义清晰，才是多窗口通信稳定高效的真正关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
