我坚持使用问题中提到的共享本地数据解决方案localStorage。它似乎是可靠性、性能和浏览器兼容性方面的最佳解决方案。

localStorage 在所有现代浏览器中实现。

storage当其他选项卡对 进行更改时会触发该事件localStorage。这对于通信目的非常方便。

参考资料可以在这里找到：
Webstorage
Webstorage - 存储事件

BroadcastChannel 标准允许这样做。现在它在 Firefox 和 Chrome ( caniuse , mdn ) 中实现：

// tab 1
var ch = new BroadcastChannel('test');
ch.postMessage('some data');

// tab 2
var ch = new BroadcastChannel('test');
ch.addEventListener('message', function (e) {
    console.log('Message:', e.data);
});

SharedWorker 是 WHATWG/HTML5 规范，用于可以在选项卡之间进行通信的通用进程。

除了即将推出的SharedWorker 之外，您还可以使用支持更广泛的跨文档消息传递。在这种情况下，必须有一个主窗口负责打开所有其他带有. 然后，子窗口可以使用的postMessage他们。window.openwindow.opener

如果您可以选择使用 flash，那么任何安装了 flash 的客户端实际上都支持更旧的LocalConnection（示例代码）。

其他回退方法：
用于 jQuery 的 postMessage 插件，带有 window.location.href 回退旧浏览器
基于 cookie 的非即时通信解决方案

你说你的：

最终目标是制作类似 facebook 的东西，如果你打开 4 个 facebook 标签，并在一个标签中聊天，聊天会在每个 facebook 标签上实现，这很整洁！

这应该作为您设计的副产品发生，视图查询模型（可能是服务器）以更新聊天，而不是您必须在跨视图通信中进行设计。除非您正在处理传输大量数据，否则为什么要担心呢？似乎它会使事情复杂化而没有巨大的收益。

多年前我发现如果我确实window.open使用了现有窗口的名称和空白 URL，我会得到对现有窗口的引用（这种行为甚至记录在 MDN上，MSDN 文档上的评论表明它也适用于 IE ；也就是说，在 2017 年，有人在 MDN 文章中添加了一些粗暴的注释，列出了一些限制——我还没有独立验证它们）。但那是几年前的事了，我不知道当今世界对它的支持有多普遍，当然除非您的所有窗口都包含一个命名的窗口名称，否则您将无法查找窗口名称iframe 用于通信，通过服务器端代码唯一命名，然后通过服务器端代码与其他窗口通信......（可怕的想法：这可能实际上是可行的。存储与记录相关的“当前”窗口名称-在表中的帐户中，将列表提供给登录该帐户的任何创建的新窗口，剔除旧的非活动条目。但如果列表稍微过时，您将在搜索其他人时打开新窗口......我下注支持从浏览器到浏览器都是不确定的。）