现代 Web 应用越来越接近桌面应用，一个网站往往会同时打开多个标签页。例如：
登录状态同步
多标签页共享数据
消息通知
只允许一个标签页执行定时任务
多标签页协同编辑
多窗口控制
这些场景都离不开浏览器标签页通信（Cross-Tab Communication）。
本文将介绍浏览器中几种常见的标签页通信方案，并分析它们各自的优缺点及适用场景。
为什么需要标签页通信？
假设用户同时打开了两个后台管理页面：
┌──────────────┐
│ 标签页 A │
│ Dashboard │
└──────────────┘
┌──────────────┐
│ 标签页 B │
│ User Center │
└──────────────┘
当用户在标签页 A 中退出登录时，希望标签页 B 能够立即退出，而不是等到刷新页面才发现 Token 已失效。
类似需求还有：
修改主题后所有页面立即生效
一个页面收到通知，其它页面同步显示
防止重复提交订单
多页面共享缓存
主页面控制子窗口
浏览器提供了不少通信方式来解决这些问题。
方案一：BroadcastChannel（推荐）
这是目前最简单、最现代的方案。
所有同源页面只要监听同一个频道即可互相通信。
Tab A
│
BroadcastChannel
│
Tab B
│
Tab C
发送消息：
const channel = new BroadcastChannel("halo");
channel.postMessage({
type: "login",
user: "admin"
});
接收消息：
const channel = new BroadcastChannel("halo");
channel.onmessage = (event) => {
console.log(event.data);
};
优点
API 简洁
支持多个标签页
实时通信
无需轮询
支持任意可序列化对象
缺点
IE 不支持
Safari 较老版本兼容性较差
适用场景
登录状态同步
主题切换
通知同步
配置同步
方案二：localStorage + storage 事件
这是兼容性最好的方案之一。
核心原理：
修改 localStorage 后，其它标签页会收到 storage 事件。
发送：
localStorage.setItem(
"message",
JSON.stringify({
type: "logout",
time: Date.now()
})
);
监听：
window.addEventListener("storage", (event) => {
if (event.key === "message") {
console.log(JSON.parse(event.newValue));
}
});
需要注意的是：
当前页面不会收到自己触发的 storage 事件。
优点
浏览器兼容性极好
实现简单
无需服务器
缺点
只能依赖 storage
数据会写入本地存储
高频通信性能一般
适合低频事件。
方案三：SharedWorker
多个标签页可以连接同一个 Worker。
Tab A ─┐
│
Tab B ──┼── SharedWorker
│
Tab C ──┘
worker：
const ports = [];
onconnect = (event) => {
const port = event.ports[0];
ports.push(port);
port.onmessage = (e) => {
ports.forEach((p) => {
if (p !== port) {
p.postMessage(e.data);
}
});
};
};
页面：
const worker = new SharedWorker("worker.js");
worker.port.start();
worker.port.postMessage("Hello");
优点
真正共享运行环境
可共享缓存
性能优秀
缺点
Safari 支持较差
实现稍复杂
适合大型 Web 应用。
方案四：Service Worker
Service Worker 可以作为所有页面之间的中转站。
Tab A
│
Service Worker
│
Tab B
例如：
self.clients.matchAll().then((clients) => {
clients.forEach(client => {
client.postMessage({
type: "refresh"
});
});
});
页面监听：
navigator.serviceWorker.addEventListener("message", (event) => {
console.log(event.data);
});
优点
支持离线
可配合 PWA
能处理 Push
适合：
Web App
PWA
离线应用
方案五：window.postMessage
如果页面之间存在引用关系：
例如：
window.open()
iframe
parent
即可使用：
otherWindow.postMessage(
{
type: "hello"
},
"*"
);
监听：
window.addEventListener("message", (event) => {
console.log(event.data);
});
优点
支持跨域
官方推荐
缺点
无法发现其它独立标签页。
方案六：Cookie 轮询
最传统的方法。
setInterval(() => {
},1000)
每秒读取 Cookie：
document.cookie
虽然能够实现同步，但：
延迟高
性能差
不推荐
一般仅用于兼容老项目。
方案七：WebSocket
所有标签页都连接服务器：
Tab A
│
Tab B ─── Server
│
Tab C
服务器负责广播：
A → Server → B
A → Server → C
优点：
跨设备
跨浏览器
实时
缺点：
需要服务器。
适合：
在线聊天
协同编辑
实时消息
方案八：IndexedDB
虽然 IndexedDB 本身不是通信 API，但结合数据库监听或定时检测，也能实现跨标签页数据同步。
例如：
Tab A
↓
IndexedDB
↑
Tab B
通常会结合：
BroadcastChannel
Service Worker
共同使用。
如何选择？
下面是一份简单的选型建议。
实战案例：同步登录状态
下面是一个简单的实现思路。
登录成功：
channel.postMessage({
type: "login"
});
退出登录：
channel.postMessage({
type: "logout"
});
其它标签页监听：
channel.onmessage = ({ data }) => {
switch (data.type) {
case "logout":
location.href = "/login";
break;
case "login":
refreshUser();
break;
}
};
这样，当一个页面退出登录时，其它页面几乎可以立即同步退出，无需刷新页面。
最佳实践建议
在实际项目中，并不存在一种方案适用于所有场景。可以根据项目特点组合使用不同技术：
现代浏览器优先选择
BroadcastChannel，实现简单、实时性好。兼容旧浏览器可退化到
localStorage + storage。涉及 PWA 或离线能力时，结合
Service Worker。需要跨设备实时同步时，使用
WebSocket。有父子窗口或 iframe 的场景，优先使用
postMessage。
此外，通信的数据应尽量保持轻量，只传递必要的信息，例如事件类型、标识符或状态，而不是大量业务数据。对于频繁发送的消息，可以增加节流、防抖或消息合并机制，避免对页面性能造成影响。
总结
浏览器标签页通信是现代 Web 应用中十分重要的一项能力。从最早的 localStorage、Cookie 轮询，到如今的 BroadcastChannel、SharedWorker 和 Service Worker，浏览器已经提供了丰富的解决方案。
如果你的项目只需要在多个同源标签页之间同步状态，那么 BroadcastChannel 是目前最值得优先考虑的方案；如果需要兼容老旧浏览器，可以使用 localStorage + storage 作为降级策略；而对于需要跨设备、跨浏览器甚至离线支持的复杂场景，则可以结合 WebSocket 与 Service Worker 构建更加完善的通信体系。
合理选择通信方案，不仅能够提升用户体验，也能让你的 Web 应用更加高效、稳定和现代化。