srcdoc需提供完整HTML文档结构，含DOCTYPE、html、head、body，禁止外部资源，脚本CSS须内联，必须配sandbox，IE不支持需fallback，适用小而隔离的场景。
srcdoc 不是用来“塞一段 div 就完事”的快捷属性，它本质是让 <iframe> 直接加载并执行一段完整的 HTML 文档字符串——这意味着你得写 <!DOCTYPE html>、<html>、<head>、<body>，否则 Safari 会空白、Chrome 可能渲染异常。
srcdoc 必须提供完整 HTML 文档结构
常见错误是只传 "<div>hello</div>"，结果 iframe 显示为空白，控制台却没报错。这是因为 srcdoc 的值被当作整个文档源码解析，不是 fragment。
- 必须显式包含
<!DOCTYPE html>（哪怕某些浏览器自动补全，也不能依赖） -
<html>、<head>、<body>标签缺一不可；<title>虽非强制，但缺失可能影响 SEO 或调试体验 - 所有双引号需转义：若内联
style="color:red"，外层属性建议用单引号定义，或写成style="color:red" - 禁止
<script src="..."></script>或<link href="...">—— 外部资源一律不加载，连相对路径都无效
内联 JS/CSS 要注意执行时机和作用域隔离
srcdoc 里的脚本无法访问父页面的 window、document 或任何全局变量，它运行在独立浏览上下文中。想通信？只能靠 postMessage。
- CSS 必须用
<style></style>内联，不能靠外部link或父页样式穿透 - JS 若操作 DOM，推荐放在
<body>底部，或包裹在DOMContentLoaded回调里，避免节点未挂载就执行 - 不要尝试
document.write()或修改contentDocument—— srcdoc 加载后文档即锁定，动态写入会失败 - 若需响应用户输入（如预览 Markdown），每次更新都应重新赋值整个
srcdoc字符串，而不是 patch 部分内容
必须配 sandbox，否则 XSS 风险直线上升
srcdoc 默认同源（即使内容来自用户输入），不加 sandbox 等于主动开放脚本执行、表单提交、弹窗等全部权限。哪怕只是渲染一个按钮计数器，也得明确最小权限。
立即学习“前端免费学习笔记（深入）”；
- 最安全起点是
sandbox=""（空值），此时脚本、插件、表单、弹窗全部禁用 - 仅当真需要 JS 执行时，才加
sandbox="allow-scripts"；若还需postMessage通信，加上allow-top-navigation即可 - 绝对避免
sandbox="allow-same-origin"—— 它会解除同源限制，让恶意脚本读取父页 DOM，哪怕 srcdoc 内容是你自己拼的，一旦混入用户输入就危险 - IE 完全不支持 srcdoc，所以必须提供 fallback：同时设
src和srcdoc，IE 自动忽略后者，走src="data:text/html;base64,..."路径
别把 srcdoc 当通用渲染器，它有明确边界
srcdoc 适合的是「小、快、隔离」——HTML 字符串长度建议控制在 10KB 以内；含大量图片、字体、第三方库的页面，它既无法加载资源，又会因字符串过长触发浏览器截断（部分 Chrome 版本对 srcdoc 值长度隐式限制约 2MB，但实际超过几百 KB 就开始卡顿）。
- 富文本编辑器右侧预览、组件库文档中的交互 demo、Logseq 笔记里嵌 CSS 效果块——这些是典型场景
- 想嵌地图、支付页、政府服务平台？必须用
src，srcdoc 不解决跨域问题，也不支持外部资源加载 - React/Vue 中直接插
srcDoc属性没问题，但记得用encodeURIComponent或模板字符串拼接，避免中文、换行、尖括号被 HTML 解析器提前截断 - 本地开发时别用
file://协议测试 srcdoc —— 某些浏览器对 data URI 或内联 HTML 的解析策略在 file 协议下更严格，起个http-server更可靠
真正容易被忽略的点是：srcdoc 渲染后，其 document 对象与父页完全隔离，连 font-family 这种基础继承都会断掉；你得把字体、重置样式、基础排版全写进 <style> 里——不是“少写点”，而是“必须全写”。
