object标签的PDF fallback无法完美实现，仅在data URL返回HTTP错误或type与Content-Type不匹配且启用typemustmatch时触发；稳定方案是改用iframe或pdf.js。
object 标签的 PDF fallback 不可能“完美”——它只在极窄条件下触发，且行为因浏览器而异；真正稳定的做法是放弃 object，改用 iframe 或 pdf.js。
fallback 触发条件比你想象的苛刻
浏览器不会因为 PDF 渲染失败（比如页面崩溃、权限拒绝、CORS 阻断）就显示 object 内部内容。它只在以下两种情况之一发生时才降级：
-
dataURL 返回 404 或 500 等 HTTP 错误状态码 -
type="application/pdf"与服务端响应头Content-Type不匹配，且启用了typemustmatch属性
常见“空白页”不是 fallback 没生效，而是根本没满足触发条件：Safari 可能静默下载，Chrome 可能卡在加载图标，Firefox 可能显示灰色占位框——这些都不算“加载失败”，所以内部 <p> 一直被忽略。
写在 object 标签体内的内容必须是纯 HTML
你塞进去的任何东西，只要带执行能力，就会让 fallback 失效或引发新错误：
立即学习“前端免费学习笔记（深入）”；
- 不能含
<script>—— 浏览器会提前执行，可能污染全局或报错中断渲染 - 不能含
<iframe>—— 它本身可能触发跨域或白屏，且不参与 fallback 生命周期 - 不能用
<div>包裹提示文字 —— HTML 规范只允许object内嵌“flow content”，<p>、<img>、<a>是安全的，<div>在部分解析器中会被剥离
正确示例：<object data="report.pdf" type="application/pdf" typemustmatch><p>PDF 加载失败，请点击下载</p></object>
param 在 fallback 下完全无意义
<param name="page" value="3"> 这类配置只对成功加载的插件实例起作用。一旦进入 fallback，整个 object 上下文已被销毁，DOM 中的 param 标签形同虚设。
如果你需要在降级时复用原始参数（比如跳转到特定页），必须提前用 JS 提取：
const obj = document.querySelector('object[data]');
const pdfUrl = obj.getAttribute('data');
// 后续在 fallback 里构造 iframe src 或下载链接时复用 pdfUrl
别指望 obj.getAttribute('data') 在 onerror 回调里还能读到值——此时属性可能已为空或被重置。
现代项目里该用什么替代 object
直接换掉，别挣扎：
- PDF 嵌入统一用
<iframe src="report.pdf">：Chrome/Firefox/Safari 均原生支持，失败时自动触发下载，loading="lazy"可开，尺寸控制稳定 - 需要页码跳转、文本搜索等高级功能，上
pdf.js：它自己管理 fallback、错误提示和降级逻辑，不依赖浏览器插件 - 禁用 JS 的场景极少，真有需求再考虑
object+typemustmatch+ 纯 HTML fallback，但得接受 Safari 和微信 WebView 的兼容性缺口
最常被忽略的一点：服务端 Content-Type: application/pdf 响应头缺失，比前端标签写错更常导致空白——Nginx 缺少 types { application/pdf pdf; } 配置，或后端动态生成 PDF 时忘了设 header，都会让 object 直接放弃渲染。
