它影响Ajax的原因是因为Ajax受相同来源策略规则的约束，当您对其进行沙箱处理时，实际上是在告诉浏览器将
iframe内容视为来自其他来源。引用同一篇文章：
- 独特的起源治疗。 所有内容均根据唯一来源处理。内容无法遍历DOM或读取cookie信息。
这意味着即使来自同一域的内容也将使用跨域策略处理，因为每个 Iframe 内容都将被视为唯一的来源。
嵌入的内容仅允许显示信息。 在 Iframe 中无法执行其他任何可能破坏托管网站或利用用户信任的操作。
换句话说，如果您
allow-same-origin在
sandbox属性中省略，它将把沙盒页面视为属于另一个域（实际上，它将被视为具有
null来源）。由于向Ajax请求没有意义，因此
null，沙盒页面根本无法进行Ajax调用（如果
localhost允许，则它们与父页面的调用是无法区分的，从而打败了沙盒的目的）。
附加信息
如果您尝试对其他域进行Ajax调用，则显然会失败：
<script src="http://pre.jquery.com/jquery.min.js"></script><script> console.log(location.host); $.post('https://google.com/',{},function() { });</script>但是，它将 如何 失败将取决于所使用的沙盒属性。如果您将上面的页面嵌入
iframe其中
allow-same-origin，它将打印到控制台：
localhostXMLHttpRequest cannot load https://google.com/. Origin http://localhost is not allowed by Access-Control-Allow-Origin.
…并且如果您嵌入而 没有
allow-same-origin：
localhostXMLHttpRequest cannot load https://google.com/. Cannot make any requests from null.
请注意，尽管两者都报告
location.host为
localhost，但其中一个认为原点是，
http://localhost而另一个认为原点是
null（显示您在示例中遇到的相同错误消息）。
推理
为什么阻止来自同一域的沙盒内容的Ajax调用如此重要？如文章所述：
在同一个域中的内容 应该 是安全的，这是有道理的。这里的风险主要来自于用户生成的内容，该内容重新托管在 Iframe中 。
让我们举一个例子：假设Facebook决定允许用户在其页面中发布一些HTML5动画。它将它们存储在自己的服务器中，并且在显示时将它们
allow-scripts仅作为沙箱存储（因为动画需要使用脚本），但是将其他所有内容都拒绝（尤其是
allow-same-origin因为您不希望用户代码弄乱父页面） ）。如果默认情况下也未阻止Ajax调用，将会发生什么情况？
Mallory创建的“动画”包括：
使用其API对Facebook执行Ajax调用（例如Open Graph）；服务器将很乐意接受该呼叫，因为对于服务器而言，它知道请求均来自具有
https://facebook.com
原始来源的页面。创建一个指向她自己的服务器的URI，并将返回的数据作为查询字符串，并将其设置为
src
沙盒页面中的图片。
当爱丽丝访问Mallory个人资料并查看动画时，上面的脚本运行：
登录Alice后，Ajax调用将在Alice的浏览器中运行；由于服务器不知道呼叫来自何处（主页或嵌入式页面），因此它将执行请求的所有操作-包括检索个人信息。
当
img
使用Mallory的URI创建该元素时，浏览器将尝试正常加载“图像”，因为图像不受相同来源政策的约束。由于URI在查询字符串中包含Alice的私人信息，因此Mallory的服务器可以保存它并返回所需的任何图像。现在，马洛里有了爱丽丝的个人信息，爱丽丝丝毫不怀疑。
