type属性必须严格匹配响应头content-type，浏览器仅在type与服务器返回的content-type完全一致时才认定类型正确；否则触发fallback，如pdf须为application/pdf、svg须为image/svg+xml。
type属性必须严格匹配响应头Content-Type
浏览器只在 type 与服务器返回的 Content-Type 响应头完全一致时，才认为资源“类型正确”。写成 type="pdf"、type="application/x-pdf" 或留空，Chrome/Firefox 都会直接 fallback。
常见错误现象：PDF 文件明明存在，却始终显示 fallback 文字；本地双击 HTML 文件（file:// 协议）时 Safari 完全不加载。
-
type必须是标准 MIME 类型，PDF 只认application/pdf，SVG 只认image/svg+xml - 服务端返回 PDF 但响应头是
text/plain？哪怕写了type="application/pdf"，也会触发 fallback（除非显式去掉typemustmatch） - 开发阶段用
http://localhost启服务，别依赖file://—— Firefox 在该协议下会忽略type，只按文件扩展名判断
data 和 type 至少填一个，但只写 type 会导致空白
如果只设 type="application/pdf" 却没写 data，浏览器会渲染一个空盒子，既不加载也不 fallback。这不是 bug，是规范行为：没有资源路径，就无从“加载失败”，自然不触发降级。
使用场景：你可能想用 JS 动态赋值 data，但初始状态必须可降级 —— 此时应在 HTML 中预设一个兜底 data（比如指向一个空 PDF 或 404 路径），或直接把 fallback 内容写实。
- 正确组合：
data+type（推荐） - 勉强可用：
data单独存在（浏览器按扩展名或响应头推断类型） - 危险组合：
type单独存在 → 空白区域，无提示，无 fallback
fallback 内容不是“没显示就出来”，而是“明确加载失败才渲染”
很多人以为只要 object 区域没内容，就会显示内部文字或 <img>，其实不然。fallback 只在以下情况触发：data 返回 404/500、CORS 阻止、协议被拒（如 file:// 加载 PDF）、type 与响应头不匹配且启用了 typemustmatch。
容易踩的坑：把 fallback 写成纯文本、<script></script> 或注释 —— 这些都不是有效子节点，浏览器直接忽略，不会渲染。
- 合法 fallback：必须是 HTML 流内容，例如
<p></p>、<img src="...">、嵌套的另一个<object></object> - 非法 fallback：纯文本（即使带空格）、
<!-- comment -->、<script></script>、<div>（HTML5 中非可替换元素，部分浏览器不认）<li>调试技巧：打开 DevTools 的 Network 面板，看 <code>data请求是否返回 200 + 正确Content-Type - PDF：设
width="100%" height="600"安全，Chrome 不依赖尺寸，Safari 16+ 需要它 - SVG：优先不设
width/height，或设为100%，并确保父容器有明确宽度（如max-width: 800px） - 跨域 SVG 引用外部资源（如
<use href="icon.svg#x"></use>）必然失败 → fallback 到<img src="icon.png">更实际
PDF 与 SVG 的 width/height 设置逻辑完全不同
对 PDF 来说，width 和 height 是容器尺寸，不影响文档渲染逻辑；但对 SVG，它们会强制覆盖 viewBox 缩放行为，导致变形或裁剪。
性能与交互影响：Safari 16+ 要求显式设置 width/height 才启用内置 PDF 查看器；而 SVG 加载后 DOM 隔离，contentDocument 仅同源可用，且 PDF 场景下该属性为 null。
真正难的不是写对标签，而是理解浏览器何时认定“加载失败”——它不看你页面有没有空白，而看网络层和 MIME 层有没有明确的错误信号。很多问题卡在服务端配置或本地协议限制上，前端单靠改 HTML 很难绕过。
