srcdoc的核心作用是让直接渲染内联HTML字符串，不发网络请求且默认隔离源；它专为内容可控、加载零延迟、安全边界清晰的小型动态场景设计，需配合sandbox使用以防范XSS风险。
srcdoc 的核心作用是：**让 <iframe></iframe> 直接渲染一段内联 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 或状态污染。
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 最简安全底线：
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 字符串必须是语法合法的完整片段（例如不能只有
<div>hello，缺闭合标签或未转义引号会导致解析失败，iframe 显示空白） <li>调试技巧：用 <code>iframe.contentDocument?.documentElement?.innerHTML检查当前渲染的实际 HTML，确认是否被浏览器自动修正或截断
真正难的不是写对 srcdoc，而是判断它是否适合你的场景——它不处理资源加载、不兼容老浏览器、不自动同步状态。一旦内容超过几百行 HTML 或需要频繁 DOM 交互，就该考虑用 Shadow DOM、Web Component 或真正的微前端方案了。
