object标签仅在PDF、SVG图表及旧系统交互文档等需原生fallback或类型校验的场景中不可替代；日常图片/音视频应优先使用img/video/audio；PDF嵌入须确保type="application/pdf"、服务端Content-Type匹配且避免file://协议。
object 标签不是“通用嵌入万金油”，它只在特定资源类型和 fallback 需求下才真正必要——比如 PDF、SVG 图表、旧系统导出的交互式文档。日常图片/音视频请直接用 img、video、audio；强行用 object 嵌入 PNG 或 MP4，反而容易触发意外 fallback 或跨域静默失败。
PDF 嵌入必须写对 type 且服务端响应头匹配
Chrome 和 Firefox 对 type="application/pdf" 敏感，写成 type="pdf"、type="text/plain" 或留空，都会拒绝渲染并 fallback。更隐蔽的问题是：服务端返回 PDF 文件但响应头是 Content-Type: text/plain，哪怕 HTML 里写了正确的 type，浏览器仍会判定 MIME 不匹配而降级。
- 本地开发时用
file://协议加载 PDF，Firefox 会忽略type，只按文件扩展名判断；Chrome 则严格校验type和响应头 —— 统一走http://localhost启服务可避免不一致 - Safari 16+ 要求显式设置
width和height（哪怕设为100%），否则内建 PDF 查看器不激活 - 加了
typemustmatch属性后，只要type和响应头不一致，必然 fallback；去掉该属性可绕过校验，但失去类型安全
SVG 嵌入后 DOM 隔离导致 JS 无法跨边界操作
用 object 加载 SVG 时，其内部是一个独立的文档上下文，主页面 JS 无法直接访问 SVG 内部元素，document.querySelector("svg g") 找不到，onclick 绑定也无效。
- 同源情况下可用
obj.contentDocument获取内部文档对象，再操作，但 PDF 场景下该属性为null -
width/height设为固定像素值会覆盖 SVG 的viewBox缩放逻辑；设为100%更安全，但父容器必须有明确宽度（如max-width: 800px） - SVG 内若含
<use href="icon.svg#x"></use>，跨域引用会失败；此时 fallback 到<img src="icon.png" alt="HTML object标签嵌入文档资源实例解析" >比硬撑更实际
fallback 不触发的常见误判场景
很多人以为“没显示出来就是 fallback 失效”，其实浏览器只在明确加载失败时才渲染 fallback 内容：404、CORS 拒绝、file:// 协议被拦截、type 与响应头不匹配等。以下情况不会触发 fallback：
立即学习“前端免费学习笔记（深入）”；
-
data指向一个真实存在的 PDF，但服务器返回 200 + 错误内容（如 HTML 错误页），浏览器认为“加载成功”就不降级 -
data为空或未提供，只写了type，结果渲染出空白区域，而非 fallback 内容 - fallback 区域写了纯文本、
<script></script>或注释，这些都不是有效 HTML 子节点；必须是<p></p>、<img alt="HTML object标签嵌入文档资源实例解析" >或嵌套的另一个<object></object> - 写了
type="image/svg+xml"却让data指向 PNG 文件，人为制造 MIME 不匹配，必然 fallback —— 这不是 bug，是设计行为
真正难处理的是那些“看似加载成功却没内容”的情况：比如 CORS 静默阻止资源解析、服务端 gzip 压缩异常导致 PDF header 损坏、或 Safari 对 object 的 width/height 计算偏差。这些不会报错，也不触发 fallback，只能靠 Network 面板查响应体和 Content-Type 字段确认。
