object fallback常不显示，因仅在明确加载失败（如404、mime不匹配）时触发，而非渲染空白即降级；data指向pdf但服务端返回text/plain、type写错或移动端强制下载均导致fallback失效。
object fallback 为什么经常不显示
因为浏览器只在明确加载失败时才触发 <object></object> 内部的备用内容，而不是“没渲染出来就降级”。常见误判场景包括：
— data 指向 PDF 但服务器返回 Content-Type: text/plain，浏览器静默跳过渲染，也不触发 fallback；
— type="application/pdf" 写成 type="pdf" 或留空，导致类型校验失败，直接放弃加载流程；
— 移动端（尤其是 iOS Safari、微信 WebView）对 PDF 的处理是强制唤起系统应用或下载，<p></p> 根本不参与渲染逻辑。
PDF 嵌入必须满足的三个硬性条件
想让 <object></object> 真正稳定显示 PDF 并 fallback，得同时满足：
— data URL 必须可访问，且服务端响应头含 Content-Type: application/pdf；
— type 属性必须严格写成 application/pdf，不能简写、不能大小写混用；
— 宽高建议用 CSS 控制（如 style="width:100%; height:600px;"），避免 width/height 属性在响应式布局中被忽略或截断。
fallback 不可靠时的 JS 补救方案
当 <object></object> 内部文字不渲染，又必须提示用户时，可用轻量 JS 检测：
— 监听 load 和 error 事件（注意：PDF 加载失败时 error 常不触发）；
— 定时检查 offsetHeight 是否为 0，持续 2s 未变化则判定加载失败；
— 若检测失败，手动显示一个 <div class="pdf-fallback">... 提示层，并提供下载链接；<br>— 避免依赖 <code>onload 属性写法，统一用 addEventListener 绑定，防止多次绑定或覆盖。
SVG 图表这类非标准资源怎么 fallback
SVG 是少数仍能发挥 <object></object> 优势的现代场景，但要注意：
— data 必须指向真实 SVG 文件（不是 PNG/JPG），且服务端返回 Content-Type: image/svg+xml；
— 内部 fallback 可放一个 <img src="chart-fallback.png" alt="...">，这是合法且会被渲染的；
— 不要嵌套 <object></object> 或 <iframe></iframe> 作为 fallback，它们在降级路径里不会二次执行；
— 如果 SVG 需要 JS 交互，确保它内联在文件中（而非用 <use></use> 引用外部 symbol），否则 <object></object> 加载后脚本无法访问其 DOM。
真正难的不是写对标签，而是判断什么时候该放弃 <object></object> —— 比如嵌入第三方地图、表单或音视频，<iframe></iframe> 或原生 <video></video> 才是确定性选择。而 <object></object> 的价值，只在需要类型校验 + 原生 fallback + 非标准 MIME 的窄缝里才不可替代。
