可以说，SharedArrayBuffer 在
网络，但一切已经趋于平稳。以下是您需要知晓的相关信息：
简述
SharedArrayBuffer目前支持 Firefox 79 及更高版本，并将在 Android 设备上推出。 Chrome 88。不过，它仅适用于跨域隔离的网页。SharedArrayBuffer目前适用于桌面版 Chrome，但可通过 Chrome 使用 92 则仅限于跨源隔离的网页。如果您认为 可及时进行这项更改，您可以注册源试用，以便在至少在 Chrome 之前保留当前行为 第 113 页。- 如果您打算启用跨域隔离功能以继续使用
SharedArrayBuffer会评估这会对其他跨源造成的影响 元素，例如广告展示位置。检查SharedArrayBuffer来了解您的任何第三方资源的影响和 指南。
跨域隔离概览
您可以使用以下代码提供网页，以实现跨源隔离 标头：
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
执行此操作后，除非出现以下情况，否则您的网页将无法加载跨源内容：
资源通过 Cross-Origin-Resource-Policy 明确允许
标头或 CORS 标头
（Access-Control-Allow-* 等）。
此外还有报告 API，因此您可以
可以收集因以下原因而失败的请求的相关数据：
Cross-Origin-Embedder-Policy和Cross-Origin-Opener-Policy。
如果您认为无法及时在 Chrome 92 中完成这些更改，可以 注册源试用以保留当前的桌面版 Chrome Chrome 113 之前的版本。
请参阅本页底部的深入阅读部分 了解有关跨域隔离的更多指导和信息。
我们是如何发展至今的呢？
SharedArrayBuffer 已在 Chrome 60 中推出（日期为 2017 年 7 月，
想想日期时间，而不是 Chrome 版本），一切都很棒。
期限为 6 个月。
2018 年 1 月，我们发现了一些热门 CPU 中存在一个漏洞。请参阅 通知 但这实质上意味着代码可以使用高分辨率 使用计时器读取不应访问的内存。
这对我们的浏览器供应商来说是个问题 以 JavaScript 和 WASM 形式编写代码，但要严格控制 哪些资源可以使用如果您进入我的网站，我应该就没法阅读 您打开的任何网上银行网站的任何信息。事实上，我不应该 您也能访问自己的银行账号这些是 网络安全。
为了缓解这个问题，我们降低了高分辨率计时器的分辨率，例如
名称：performance.now()。不过，您可以创建高分辨率计时器，具体方法是：
SharedArrayBuffer，方法是在 worker 的紧密循环中修改内存，并读取
把它放回另一个线程中要有效缓解此问题，
对恶意代码造成严重影响，因此已停用 SharedArrayBuffer
一般的缓解措施是确保网页的系统进程不包含 来自别处的敏感数据Chrome 对多进程技术进行了投资 架构（还记得这本漫画吗？），但 仍然会遇到来自多个网站的数据最终会在同一个进程中的情况：
<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->
这些 API 具有“旧版”一种行为，允许来自其他来源的内容 而无需从其他来源选择启用。这些请求是通过 因此是一个完整的“登录”状态请求。时至今日， API 要求其他源站选择启用 CORS。
我们解决了这些旧版 API 问题，阻止了内容进入 网页的进程（如果其显示有误），并称为跨源读取屏蔽。 在上述情况下，我们不允许 JSON 进入该进程，因为它 是其中任何 API 的有效格式。也就是说，iframe 除外。对于 iframe 将内容放在不同的进程中。
实施这些缓解措施后，我们在 Chrome 中重新引入了 SharedArrayBuffer
68（2018 年 7 月），但仅适用于桌面设备。额外的流程要求意味着
无法在移动设备上执行相同的操作。还有一项指出，Chrome 的解决方案
并不完整，因为我们只屏蔽了“不正确”数据格式，
可能（尽管不常见）的是
包含私有数据
网络标准的人员共同制定了一个更完善的跨浏览器
解决方案。解决方法是为网页提供以下表述：“本人特此放弃我的
无需用户同意即可将其他来源的内容纳入此流程。”
此声明通过 COOP 和 COEP 标头完成
随网页一同提供。浏览器强制要求执行该操作，作为交换，网页获得
对 SharedArrayBuffer 和具有类似功能的其他 API 的访问权限。其他来源
可以通过
Cross-Origin-Resource-Policy
或 CORS。
Firefox 是率先采用此限制的 SharedArrayBuffer，
版本 79（2020 年 7 月）。
然后，在 2021 年 1 月，我写了这篇文章，您读着它。你好。
这就是我们现在所处的位置。Chrome 88 重磅回归 SharedArrayBuffer
Android 适用于跨源隔离的网页，Chrome 92 也提供相同的
对桌面平台的要求，这既是为了保持一致性，又是为了实现全面的跨源访问
隔离。
延迟对桌面版 Chrome 的更改
这是“源试用”形式的临时例外情况让人们
有更多时间来实现跨源隔离网页。它支持
SharedArrayBuffer，而无需对网页进行跨源隔离。通过
该例外会在 Chrome 113 中过期，并且该例外仅适用于桌面版
Chrome。
- 为您的源请求令牌。
- 将令牌添加到您的网页。您可以采用下列两种方法：
<ph type="x-smartling-placeholder">
- </ph>
- 在每个网页的标头部分添加
origin-trial<meta>标记。例如： 可能如下所示：
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - 如果您可以配置服务器，还可以添加令牌
使用
Origin-TrialHTTP 标头。生成的响应标头应 大致如下所示：
Origin-Trial: TOKEN_GOES_HERE
- 在每个网页的标头部分添加
深入阅读
横幅照片由丹尼尔提供 Gregoire 在 Un 应用程序 中畅饮