srcdoc的核心作用是让直接渲染内联HTML字符串，不发网络请求且默认隔离源；它专为内容可控、加载零延迟、安全边界清晰的小型动态场景设计，需配合sandbox使用以防范XSS风险。
srcdoc 的核心作用是：**让 直接渲染一段内联 HTML 字符串，不发网络请求，且默认隔离源（same-origin policy 无效，但同源脚本仍被阻止）**。它不是 src 的替代品，而是为「小、快、隔离」场景设计的专用通道。
什么时候该用 srcdoc 而不是 src 或 data:text/html,？
选 srcdoc 是因为你要兼顾三件事：内容可控、加载零延迟、安全边界清晰。
- 需要实时预览用户输入的 HTML 片段（比如 Markdown 预览器、富文本编辑器右侧面板），
srcdoc可直接赋值字符串，无需编码成 data URI，也避免跨域或 CSP 阻断data:协议 - 想绕过服务端渲染或静态文件依赖——比如组件库文档页里嵌一个带交互的 demo，HTML 和 JS 全部由 JS 拼好后塞进
srcdoc，连.html文件都不用存 - 对比
src="data:text/html,..."：srcdoc不受Content-Security-Policy中data:协议限制（只要没显式禁止 inline HTML），也不触发浏览器对 data URI 的额外解析开销 - 注意：如果内容含大量 JS/CSS/图片资源，
srcdoc就不合适了——它只接受纯 HTML 字符串，所有外部资源仍需通过网络加载，且受 iframe 的sandbox约束
srcdoc 必须配 sandbox 吗？不配会怎样？
不强制，但不配等于裸奔。没有 sandbox 时，srcdoc 内容默认拥有完整执行权限（包括脚本、表单提交、弹窗），且与父页面共享 document.domain（若可设置），极易引发 XSS 或状态污染。
- 最简安全底线：
sandbox="allow-scripts allow-same-origin"—— 允许运行脚本，同时允许访问同源 DOM（否则contentDocument读取会失败） - 若只需展示静态内容，去掉
allow-scripts；若要调用父页面 API，加allow-popups-to-escape-sandbox（仅限现代浏览器） - Firefox 25+、Chrome 20+、Safari 6+ 支持
srcdoc，但 Edge（旧版）完全不支持，此时会自动 fallback 到src；所以生产环境必须提供src作为降级路径 - 别信
seamless属性——它已被所有主流浏览器废弃，对样式继承或滚动条隐藏毫无作用
动态更新 srcdoc 时常见的坑
直接改 iframe.srcdoc = newHtml 看似简单，但实际行为和预期常有偏差。
- 每次赋值都会触发 iframe 重载（类似刷新），已运行的 JS 上下文全部销毁，
console.log、定时器、事件监听器全失效 - 如果新 HTML 字符串里含
<script></script>标签，它们会在新上下文中重新执行；但若脚本依赖父页面变量（如window.api），会报ReferenceError—— 因为 sandbox 默认切断了对父 window 的访问 - HTML 字符串必须是语法合法的完整片段（例如不能只有 hello，缺闭合标签或未转义引号会导致解析失败，iframe 显示空白）
- 调试技巧：用
iframe.contentDocument?.documentElement?.innerHTML检查当前渲染的实际 HTML，确认是否被浏览器自动修正或截断真正难的不是写对
srcdoc，而是判断它是否适合你的场景——它不处理资源加载、不兼容老浏览器、不自动同步状态。一旦内容超过几百行 HTML 或需要频繁 DOM 交互，就该考虑用 Shadow DOM、Web Component 或真正的微前端方案了。 - 调试技巧：用
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
