摘要：所有标签页（只要它们同源）共享同一份 CookIE 和 IndexedDB 数据库，但它们各自拥有独立的 JavaScript 运行时环境和内存空间。因此，核心挑战在于：如何在一个标签页中触发一个动作，并通知其他所有同源标签页进行响应？
在现代 Web 应用中，用户在一个站点上同时打开多个标签页已是常态。
如果这些标签页之间的数据和状态无法同步，就会导致用户体验的割裂和数据的不一致，给用户带来困惑。
浏览器为了安全和稳定，默认将每个标签页设计为独立的、沙箱化的环境。那么，我们如何才能打破这层“壁垒”，让它们之间进行有效“对话”呢？
所有标签页（只要它们同源）共享同一份 CookIE 和 IndexedDB 数据库，但它们各自拥有独立的 JavaScript 运行时环境和内存空间。因此，核心挑战在于：如何在一个标签页中触发一个动作，并通知其他所有同源标签页进行响应？
下面，我们来逐一分析几种解决方案。
1. localStorage+ storage事件
这是实现跨标签页通信最经典、兼容性最好的方法。
localStorage 是浏览器提供的持久化本地存储方案，数据在同源的所有标签页之间是共享的。当一个标签页通过 setItem、removeItem 或 clear 方法修改 localStorage 时，浏览器会在其他同源的标签页中触发一个 storage 事件。
关键点在于触发修改的标签页本身不会收到这个事件通知，这正是它被设计用于跨标签页通信的精妙之处。
假设当用户登录时，我们存入一个 session 令牌。
// 标签页 A：用户执行登录操作function login(token) { localStorage.setItem('session', JSON.stringify({ token, timestamp: Date.now }));}// 标签页 B、C、D...：监听 storage 事件window.addEventListener('storage', (event) => { if (event.key === 'session') { if (event.newValue) { console.log('检测到登录状态变化，更新UI为登录态'); } else { console.log('检测到登出状态变化，更新UI为登出态'); } }});兼容性极佳、API 简单直观，但只能存储字符串，事件触发有局限：只能监听到修改，无法主动发送“瞬时”消息。
2. BroadcastChannelAPI：现代通信方案
BroadcastChannel 是一个专门为跨浏览器上下文（包括标签页、窗口、iframe、Web Worker）通信设计的 API。它创建了一个命名的“频道”，所有连接到该频道的上下文都可以自由地发送和接收消息。
它遵循一个简单的“发布-订阅”模式。
创建一个 BroadcastChannel 实例，并指定一个频道名称。使用 .postMessage 方法向频道广播消息。所有连接到同名频道的其他上下文都会通过 onmessage 事件接收到该消息。// 创建一个名为 'cart_channel' 的频道const cartChannel = new BroadcastChannel('cart_channel');// 标签页 A：用户添加商品到购物车function addToCart(product) { // 更新当前页面的购物车逻辑 updateLocalCart(product); // 向所有其他标签页广播这个事件 cartChannel.postMessage({ type: 'ADD_ITEM', payload: product });}// 标签页 B、C、D...：监听频道消息cartChannel.onmessage = (event) => { const { type, payload } = event.data; if (type === 'ADD_ITEM') { // 更新当前页面的购物车逻辑 updateUIWithNewItem(payload); } else if (type === 'CLEAR_CART') { // 可以添加其他类型的处理逻辑 }};// 页面关闭时，记得关闭频道连接window.addEventListener('beforeunload', => { cartChannel.close;});API 设计优雅、支持复杂数据、低延迟：消息传递效率高，只是不支持 IE 和一些老版本的浏览器。
3. SharedWorker：强大的中央状态管理器
SharedWorker 是一种特殊的 Web Worker，它可以被多个同源的浏览器上下文（标签页、窗口等）共享。这意味着所有标签页可以连接到同一个 SharedWorker 实例，由它来扮演一个中央协调者或状态管理器的角色。
创建一个 shared-worker.js 脚本文件，其中包含共享的逻辑。
// `shared-worker.js`const connectedPorts = ;let sharedState = { count: 0 };self.onconnect = (event) => { const port = event.ports[0]; connectedPorts.push(port); // 当有新标签页连接时，立即发送当前状态 port.postMessage({ type: 'SYNC_STATE', state: sharedState }); port.onmessage = (e) => { const { type } = e.data; if (type === 'INCREMENT') sharedState.count++; // 将更新后的状态广播给所有连接的标签页 connectedPorts.forEach(p => { p.postMessage({ type: 'STATE_UPDATE', state: sharedState }); }); }; port.start;};在每个标签页中，创建一个 SharedWorker 实例来连接到这个 worker 与之通信。
// `main.js` (在每个标签页中运行)const worker = new SharedWorker('shared-worker.js');// 向 SharedWorker 发送消息document.getElementById('increment-btn').onclick = => { worker.port.postMessage({ type: 'INCREMENT' });};// 接收来自 SharedWorker 的消息worker.port.onmessage = (e) => { const { type, state } = e.data; console.log('收到来自 SharedWorker 的状态:', state);};worker.port.start;相对于前两种方案，编码和调试更复杂，与 BroadcastChannel 类似，均不支持老旧 IE。
对于绝大多数现代应用，优先考虑 BroadcastChannel，它提供了最佳的平衡点——功能强大且简单易用。
但如果我们的应用必须支持 IE 或其他旧版浏览器，localStorage 是一个可靠的降级方案。
当客户端状态逻辑变得异常复杂，多个标签页可能同时修改数据导致冲突时，SharedWorker 能够提供一个清晰、健壮的架构。
通过合理选择并应用这些技术，我们可以打造出无缝、一致的多标签页用户体验，让 Web 应用更加专业和贴心。
来源：不秃头程序员
