srcdoc属性允许在iframe中直接嵌入html内容，无需外部请求，适用于小型、动态或需隔离的场景。1. 使用srcdoc可避免http请求，提升渲染速度，适合预览用户输入的html、展示代码片段或组件；2. 与src属性相比，srcdoc为内联内容，而src加载外部资源，前者适合静态或动态小内容，后者适合大型或频繁更新的页面；3. 安全性方面，srcdoc默认具有唯一源隔离，但必须配合sandbox属性使用，如sandbox="allow-scripts"可允许脚本执行，同时限制其他权限，防止xss攻击；4. 实际应用包括富文本编辑器预览、在线代码演示、邮件模板测试、spa中安全渲染html及广告内容隔离，均依赖其内联、快速、隔离的特性完成安全高效的嵌入。
srcdoc属性允许你直接在
iframe标签内部嵌入完整的HTML内容，而不是通过URL加载外部文件。这意味着你可以在父级HTML中直接定义
iframe的整个文档结构，包括
<html>、
<head>和
<body>，实现
iframe内容的内联。
解决方案
当你需要在一个
iframe里展示一些动态的、或者说体积不大的HTML内容时，而且不希望额外创建文件或者发起HTTP请求，
srcdoc属性简直就是为你量身定制的。想象一下，你要预览用户提交的一段HTML代码，或者只是想展示一个隔离的组件，甚至是快速演示一个代码片段，这时候你就不需要给
src指向一个URL了，直接把HTML字符串塞进
srcdoc就行。
比如说，你可以这样写：
<iframe srcdoc="<!DOCTYPE html><html><head><title>内联内容示例</title><style>body { font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif; background-color: #f8f8f8; padding: 20px; border-radius: 8px; box-shadow: 0 2px 4px rgba(0,0,0,0.1); }</style></head><body><h1>来自srcdoc的问候！</h1><p>这段内容完全是内联在iframe里的，没有额外的网络请求。</p><script>console.log('srcdoc内部的脚本已执行！');</script></body></html>"></iframe>这功能特别强大，因为它让所有东西都自给自足，全部封装在一个地方。没有服务器往返，通常也不会有CORS问题，就是纯粹的、即时的渲染。当然，如果你的文档非常庞大复杂，或者内容需要频繁从服务器更新，那还是老老实实地用
src指向一个URL更合适。但对于那些快速、隔离的嵌入场景，
srcdoc简直是救星。
srcdoc
与src
属性的主要区别和适用场景
这俩兄弟看起来都是给
iframe装内容的，但骨子里完全不一样，用起来也各有侧重。
src属性，这个我们太熟悉了，它就是告诉
iframe去哪个URL加载内容。这是最标准、最常见的方式，特别适合加载外部网站、大型文档，或者那些内容会不断更新的页面。你加载的内容可以是另一个域名下的，也可以是同域名下的某个HTML文件。它的好处在于，内容是独立的，可以被浏览器缓存，而且不同源的内容之间有天然的沙盒隔离（尽管可以通过
postMessage通信）。
而
srcdoc呢，它直接把HTML代码字符串作为
iframe的内容。这就意味着，
iframe里的所有东西——从
<!DOCTYPE html>到
</html>，都直接写在了父页面的HTML里。它最大的优势就是“内联”和“即时”。没有网络请求，渲染速度飞快，非常适合那些小型、动态生成、或者需要高度隔离的HTML片段。比如，你想在不离开当前页面的情况下，快速预览一段用户输入的富文本内容，或者展示一个无需外部资源的小组件，
srcdoc就能派上大用场。
从性能上看，
srcdoc由于避免了网络请求，对于小内容来说启动速度更快。但如果你的HTML字符串非常大，那它会增加父页面HTML的体积，解析成本可能会上升。维护性方面，
src允许你把
iframe内容单独放在一个文件里，结构更清晰。
srcdoc如果内容过多，父页面的HTML会显得很臃肿，可读性会下降。所以说，选择哪个，得看你的具体需求和内容的特性。
使用srcdoc
时需要注意的安全性和沙盒（Sandbox）策略
用
srcdoc来内联内容，听起来很方便，但在安全方面可得留个心眼。
iframe的安全性本身就是个复杂的话题，而
srcdoc在这里扮演的角色也挺特殊。
首先要明确一点：
srcdoc加载的内容，浏览器会把它当作一个“独一无二的、不透明的源”（unique opaque origin）来处理，这意味着它跟父页面的源是完全不同的。所以，默认情况下，
srcdoc里的脚本是无法直接访问父页面的DOM，反之亦然。这本身提供了一定程度的隔离。
但真正能让你掌控安全性的，是
iframe的
sandbox属性。这个属性就像给
iframe上了一道道锁，用来限制其内部内容的权限。如果你不加
sandbox，尽管
srcdoc的源是唯一的，但它内部的脚本依然拥有很多权限，比如执行JavaScript、提交表单、弹出窗口等等，这在处理不受信任的内容时是相当危险的。
sandbox属性可以接受多个值，每个值都代表一种允许的权限。如果你只是写
sandbox=""（空字符串），那就意味着应用了所有可能的限制，这是最严格、最安全的模式。在这种模式下，
iframe里的内容几乎什么都不能做，脚本无法执行，无法提交表单，无法弹出窗口，甚至无法加载外部资源。
常见的
sandbox值包括：
allow-scripts
: 允许执行JavaScript。allow-same-origin
: 允许内容被视为同源，这对于srcdoc
来说有点特殊，它通常意味着允许访问localStorage或sessionStorage。allow-popups
: 允许弹出新窗口。allow-forms
: 允许提交表单。allow-top-navigation
: 允许内容导航顶层浏览上下文（也就是让父页面跳转）。
比如，如果你只想让
srcdoc里的JavaScript能跑起来，但又不想它能弹出窗口或者提交表单，你可以这样写：
<iframe sandbox="allow-scripts" srcdoc="...">。
特别是在你用
srcdoc来展示用户生成的内容时，
sandbox属性是你的救命稻草。你必须非常谨慎地选择要授予的权限。通常，你会希望尽可能地限制，以防止跨站脚本攻击（XSS）或其他恶意行为。比如，如果你只是想展示HTML结构，完全不需要脚本，那么
sandbox=""可能是最好的选择。如果非要允许脚本，那就要确保你对用户输入做了严格的净化处理。
srcdoc
在现代前端开发中的实际应用场景
srcdoc这个属性，虽然可能不像
src那样被天天挂在嘴边，但在很多特定场景下，它简直是解决问题的利器，尤其在现代前端开发中，它的价值不容小觑。
一个非常典型的应用场景就是富文本编辑器（WYSIWYG Editor）的预览功能。当你用一个富文本编辑器（比如Quill、TinyMCE或自研的）编辑内容时，编辑器通常会在后台实时生成HTML代码。为了让用户即时看到渲染效果，最直接的方式就是把这段HTML代码塞进一个
srcdoc的
iframe里。这样，用户每敲一个字、每改一个样式，预览区域就能立即更新，而且这个预览是完全隔离的，不会影响到主页面的布局或样式。
再比如，在线代码沙盒或代码演示平台。虽然像CodePen或JSFiddle这种大型平台，为了实现更复杂的隔离和功能，可能会使用
src加载后端生成的独立页面，但对于一些小型的、自包含的代码片段演示，或者在教程中嵌入一个可交互的示例时，
srcdoc就非常方便。你可以直接把HTML、CSS、JS组合成一个字符串，然后用
srcdoc渲染出来，用户可以即时看到效果，甚至在里面做一些简单的交互。
另一个很实用的地方是邮件模板的预览。邮件客户端对HTML和CSS的支持千差万别，所以在开发邮件模板时，经常需要反复测试。利用
srcdoc，你可以快速地把生成的邮件HTML代码渲染在一个
iframe里，模拟邮件客户端的显示效果，而且可以方便地在不同
iframe里切换
sandbox模式来模拟不同的客户端行为或安全限制。
在一些单页应用（SPA）中，你可能遇到这样的情况：需要在一个组件内部渲染一小段来自数据库的、带有HTML标签的文本，但又不希望这段HTML影响到主应用的CSS或JS上下文。这时候，
srcdoc就能提供一个干净的、隔离的渲染环境。你只需要把那段HTML字符串赋值给
srcdoc，它就会在一个独立的
iframe里安全地显示出来，避免了潜在的样式冲突或脚本注入风险。
最后，它在广告渲染或第三方内容嵌入方面也有潜在应用。为了安全地展示来自不可信来源的广告或内容，同时又要限制其对主页面的影响，
srcdoc配合严格的
sandbox策略，可以提供一个相对安全的沙盒环境，防止恶意脚本执行或内容“破框”而出。
