fallback内容必须写在<object>标签内部且仅限静态HTML元素，type属性须显式声明为application/pdf，服务端需返回正确Content-Type，onerror不可靠，推荐优先使用<iframe>嵌入PDF。
fallback内容必须写在
浏览器只会在
- 允许的降级内容：
<p>、<img>、<a>、<strong>等静态HTML元素 - 禁止的降级内容：
<script>、<iframe>、<video>、<canvas>等可执行或需资源加载的标签 -
<param>标签完全不参与fallback——它只作用于成功加载的插件实例，失败时被忽略 - 不要用
<div>包裹降级文本：HTML规范限制
type属性必须显式声明为application/pdf
没写type="application/pdf"，Firefox可能直接下载PDF而不是尝试渲染；Chrome则可能因MIME类型未匹配而跳过内置PDF查看器，导致fallback提前触发——你看到的“降级”其实不是失败，而是浏览器根本没走渲染路径。
- 务必写全：
type="application/pdf"，不能简写为type="pdf"或留空 - 如果PDF来自后端动态URL（含token或中文路径），确保
data值已用encodeURIComponent()编码，否则net::ERR_INVALID_URL会静默触发fallback - 服务端必须返回
Content-Type: application/pdf，Nginx需配置types { application/pdf pdf; }，否则Chrome可能拒绝内嵌而直接下载
onerror事件不可靠，别指望它兜底
现代浏览器对
- 真正可靠的fallback只有HTML原生机制——即写死在
<object>...</object>之间的内容 - 若需JS增强（比如检测移动设备后自动跳转），必须提前提取
data值存为变量，再在onerror里操作DOM，而非依赖this.getAttribute('data')——失败状态下该属性常为空 - 验证fallback是否真生效，不能靠刷新页面：浏览器缓存加载失败状态，要清缓存或用隐身窗口+禁用缓存调试
比起object，iframe才是PDF嵌入的实际首选
不是所有fallback都值得花时间调——<object>的降级逻辑受浏览器实现差异拖累太大，而<iframe src="xxx.pdf">在Chrome/Firefox/Safari中行为一致，天然支持loading="lazy"，且失败时白屏可配合CSS伪类或JS检测补救。
立即学习“前端免费学习笔记（深入）”；
-
<iframe>不需要type或<param>，无fallback语法负担 - 同源PDF直接渲染；跨域需服务端配CORS，否则静默白屏（无控制台报错）
- 微信WebView对
<object data="xxx.pdf">路径解析不稳定，但<iframe src="xxx.pdf">兼容性更好 - 如果必须保留
<object>的fallback看着简单，但每个环节都卡在浏览器实现细节上。最省事的做法：换<iframe>，把精力留给真正需要JS干预的场景。 
