关于跨选项卡和跨域通信有很多问题，但我特别问的是Safari。自第7版以来，该浏览器在iframes中添加了对第三方跟踪的阻止。所以当在iframe内部使用时，localStorage事件和BroadcastChannel在该浏览器上不起作用。
我的问题是：Safari是否有其他跨域通信解决方案(iframe和不同选项卡中同源页面之间)？
在我的库sysend.js中，我添加了一个免责声明，即跨域(与任何其他库相同)在Safari 7+上不起作用。但也许有一些技巧可以让这种沟通发挥作用。
编辑：
Safari:的状态
- 您可以使用postMessage将数据发送到iframe
- 您可以使用存储API从iframe发送事件，但数据不会像其他浏览器中那样从iframe发送到与iframe来源相同的其他页面
- 您可以在iframe中使用BroadcastChannel，但相同的数据不会从iframe发送到其他有羞耻感的页面
这基本上意味着，将数据从iframe发送到同源选项卡的解决方案都不起作用。iframe代理是我所知道的跨域通信的唯一方式。
关于iframe沙盒的注意事项
如果iframe使用sandbox属性，则可能需要allow-same-origin
允许同源：如果不使用此令牌，资源将被视为来自一个特殊的源，该源总是无法通过同源策略(可能会阻止访问数据存储/cookie和一些JavaScript API)。
存储访问API
您可能有兴趣阅读有关Storage Acess API(链接：MDN文章、W3C社区组草案报告)(目前在Edge、Firefox和Safari上受支持)的信息。
引用MDN文章：
存储访问API为嵌入式跨源内容提供了一种方法，使其能够不受限制地访问通常只能在第一方环境中访问的存储(我们将其称为源的第一方存储)。
API提供了允许嵌入式资源检查它们当前是否有权访问其第一方存储的方法，并请求用户代理访问它们的第一方存储。
[…]
出于安全原因，默认情况下无法授予沙盒
<iframe>存储访问权限。
请注意，要在沙盒iframe中运行的脚本中使用此API，iframe需要具有以下权限：allow-storage-access-by-user-activation、allow-scripts、allow-same-origin。
Window.postMessage
注：jcubic知道Window.postMessage，这是我在阅读他的一篇关于他的图书馆的文章后了解到的。我把这个答案留在这里是为了其他偶然发现这个问题的人。
从Window.postMessage上的MDN页面：
window.postMessage()方法安全地实现了Window对象之间的跨原点通信；例如，在页面和它产生的弹出窗口之间，或者在页面和嵌入其中的iframe之间。通常，当且仅当不同页面上的脚本所源自的页面共享相同的协议、端口号和主机(也称为"同源策略")时，才允许它们相互访问。
window.postMessage()提供了一种可控机制来安全地规避这一限制(如果使用得当)。一般来说，一个窗口可以获得对另一个窗口的引用(例如，通过
targetWindow = window.opener)，然后在其上用targetWindow.postMessage()调度MessageEvent。然后，接收窗口可以根据需要自由处理此事件。传递给window.postMessage()的自变量(即"消息")通过事件对象暴露给接收窗口。
我相信第一段可能会有所改进。我敢肯定，这真的意味着要对浏览上下文之间的交流做出更广泛的声明。
在其注释部分：
任何窗口都可以在任何其他窗口上随时访问此方法，无论文档在窗口中的位置如何，都可以向其发送消息。
那么，为了回答您的问题(">是否有其他针对Safari的跨域通信(iframe和不同选项卡中同源页面之间)的解决方案")：canius表示，Safari支持此API。
然后问题就变成了：如何将一个Window引用到另一个Window？您可以很容易地获得在同一浏览上下文中对iframeWindow的引用，但当它们不在同一个浏览上下文中时呢？MDN文章列出了window.opener，它在非常特殊的情况下有效，当您想要接收消息的页面是您想要发送消息的页面打开的页面时，并且没有进行任何配置来不设置window.opener。我相信，除此之外，你可能只能通过浏览器扩展的权限来实现浏览上下文之间的初始连接(我在这方面没有经验)。如果这样的事情是可能的，那就意味着你的用户/使用JS库制作的任何东西的用户都需要安装一个浏览器扩展来处理这种情况，我很确定每个浏览器都有不同的API来构建扩展，以及它们赋予扩展的功能(这可能是构建和维护的一件痛苦的事情)。