object 标签仅在需多层降级或嵌入非标准 MIME 类型资源时必要，如 PDF/SVG；必须用它而非 iframe 或 embed 的场景是：需原生 fallback、类型校验及失败时自动渲染后备内容。
object 标签现在基本只在需要**多层降级能力**或**嵌入非标准 MIME 类型资源**时才值得用，比如内嵌 PDF、SVG 图表、旧系统导出的交互式文档；日常图片/音视频请直接用 img、video、audio。
什么时候必须用 object 而不是 iframe 或 embed
当你要嵌入一个资源，并且明确要求：浏览器加载失败时自动展示后备内容（无需 JS）、资源类型可能不被原生支持、又不想依赖已废弃的 embed（无语义、无降级机制）——这时 object 是唯一原生支持完整 fallback 链路的方案。
-
iframe会始终尝试加载 URL，哪怕返回 404，也不会渲染内部内容；object遇到 404、MIME 不匹配、插件缺失等任一失败条件，就立刻切换到内部子内容 -
embed没有后备内容机制，也不支持param，现代浏览器对其支持越来越弱，且无法通过typemustmatch控制校验逻辑 - PDF 嵌入是典型场景：
<object data="report.pdf" type="application/pdf"><p>PDF 加载失败，请下载查看。</p></object>—— Chrome 显示内建 PDF 查看器，Safari 若禁用 PDF 插件则显示p标签
data 和 type 必须同时存在且语义一致
type 不是可选提示，而是参与加载决策的关键信号；浏览器会拿它和响应头 Content-Type 做比对，不一致就触发 fallback。加 typemustmatch 属性可强制校验（HTML5 新增），避免“明明返回了 HTML 却硬塞进 object 当 PDF 渲染”这类错位。
立即学习“前端免费学习笔记（深入）”；
- 如果服务端返回 PDF 文件但响应头是
text/plain，即使写了type="application/pdf"，也会 fallback（除非去掉typemustmatch） - 本地开发时用 file:// 协议加载 PDF，部分浏览器（如 Firefox）会忽略
type，直接按文件扩展名判断；此时建议配合data使用绝对路径或改用 HTTP 服务预览 - 不要写
type="image/svg+xml"却让data指向一个 PNG 文件——这属于人为制造不匹配，必然 fallback
object 内部的后备内容怎么写才有效
后备内容不是“随便放点文字就行”，它必须是**可渲染的 HTML 片段**，且不能仅靠空格、注释或不可见元素撑开结构；浏览器只在确定主资源彻底不可用后才激活它，所以它得能独立存在。
- 推荐结构：
<object data="chart.svg" type="image/svg+xml"><img src="chart-fallback.png" alt="图表静态截图"></object>—— SVG 失败时降级为图片，比纯文本更实用 - 避免只写
<p>加载失败</p>：没有尺寸定义，可能导致布局塌陷；加上style="font-size:14px; color:#666;"更稳妥 - 可以嵌套另一个
object实现二级降级，例如先试 SVG，失败再试 Canvas 渲染版本：<object data="chart.svg"><object data="chart-canvas.html"><p>请升级浏览器</p></object></object>
现代项目中容易被忽略的兼容性细节
看似简单的 object 在跨域、CSP、移动端 Safari 等场景下行为差异极大，很多问题不会报错，只会静默 fallback。
- Safari iOS 对
object加载 PDF 有严格限制：若 PDF 来自跨域且未带Access-Control-Allow-Origin，即使data可访问，也会 fallback（Chrome 则可能正常显示） - 启用 CSP 后，
object的dataURL 必须出现在child-src或object-src指令中，否则直接拦截；而iframe只需frame-src - 移动端 Android WebView（尤其旧版）对
type解析极松散，可能把application/pdf当成未知类型直接 fallback，此时去掉type反而能靠文件扩展名触发内置查看器
