跨域限制由浏览器同源策略强制实施，非HTML5本身提供；iframe无法访问跨域contentWindow、fetch需服务端CORS响应头配合、客户端存储完全隔离，推荐postMessage安全通信。
HTML5 本身不提供跨域页面限制能力，真正起作用的是浏览器的 Cross-Origin Resource Sharing（CORS）机制和 document.domain、postMessage 等 API 的配合使用。直接在 HTML 中写个标签或属性就想“限制跨域”是无效的。
iframe 跨域时无法访问 contentWindow 或 contentDocument
这是最常见的报错场景：父页用 加载后，尝试执行 iframe.contentWindow.document.body 会抛出 DOMException: Blocked a frame with origin "http://a.com" from accessing a cross-origin frame.。
- 这不是 HTML5 的“限制规则”，而是浏览器同源策略（Same-Origin Policy）的强制保护
-
allow属性（如allow="clipboard-read"）只影响 iframe 内部权限，不解除跨域 DOM 访问限制 - 若双方可控，可在子页面顶部加
document.domain = "example.com"（仅限同主域不同子域，如a.example.com↔b.example.com），但现代浏览器已逐步弃用该方式 - 推荐方案：使用
window.postMessage()进行安全通信，父页监听message事件，子页调用parent.postMessage(data, "https://parent-domain.com")
fetch 和 XMLHttpRequest 跨域请求被拒
前端 JS 发起跨域请求时，即使 URL 正确，也可能收到 net::ERR_FAILED 或控制台提示 No 'Access-Control-Allow-Origin' header。
- 关键点不在前端代码，而在服务端响应头是否包含
Access-Control-Allow-Origin -
fetch("https://api.other.com/data")默认不带凭据（cookies），若需携带，必须显式设置credentials: "include"，且服务端必须返回Access-Control-Allow-Credentials: true（此时Access-Control-Allow-Origin不能为*） - 预检请求（OPTIONS）会被自动触发：当请求含自定义 header（如
Authorization）或非简单方法（如PUT），服务端必须正确响应预检，否则请求根本不会发出
localStorage、sessionStorage 和 IndexedDB 完全隔离
跨域页面之间无法共享任何客户端存储数据——哪怕两个页面只差一个子域名，https://admin.example.com 和 https://api.example.com 的 localStorage 也是完全独立的。
立即学习“前端免费学习笔记（深入）”；
- 这不是“HTML5 规则限制”，而是浏览器按源（origin）严格划分存储空间
- 无法通过 JS 绕过；
document.cookie同理，且受SameSite属性约束 - 若需跨域同步状态，只能走服务端中转，或用
postMessage+ 主域页面做代理（例如让两个子域页面都与example.com上的中继页通信）
const iframe = document.getElementById("myIframe");
iframe.contentWindow.postMessage({ type: "GET_USER_INFO" }, "https://child-domain.com");
window.addEventListener("message", (e) => {
if (e.origin !== "https://child-domain.com") return;
if (e.data.type === "USER_INFO_RESPONSE") {
console.log("Received:", e.data.payload);
}
});
跨域真正的难点从来不在“怎么写 HTML”，而在于理解哪些操作被浏览器拦截、为什么被拦截、以及对应的安全替代路径。很多问题表面是“HTML5 限制”，实际是混淆了规范、API 行为和浏览器实现三者的边界。
