object标签不支持插件生命周期管理且无法可靠捕获加载异常，PDF嵌入fallback仅在满足三重条件时有效：服务端Content-Type严格为application/pdf、添加typemustmatch属性、避免file://协议；移动端常无视fallback；onerror/onload事件基本无效；稳定fallback需用iframe或JS主动检测降级。
object 标签在现代浏览器中**不支持插件生命周期管理，也不提供可靠的加载异常捕获能力**——它不是为容错设计的，而是为“能用就用，不能用就 fallback”这种简单逻辑服务的。真正能稳定 fallback 的，仅限 PDF 嵌入，且必须满足三重硬性条件。
PDF 嵌入时 fallback 不触发的常见原因
你以为写了 <p>下载失败</p> 就万事大吉，但实际经常白屏、静默失败、或直接跳转系统 PDF 应用：
-
data指向file://协议路径：Chrome/Firefox 会拒绝加载，不触发 fallback，也不报错 - 服务端返回
Content-Type: text/html或application/octet-stream：浏览器尝试渲染 HTML 或发起下载，<object></object>不认为这是“加载失败”，fallback 被跳过 - 没加
typemustmatch属性：即使响应头错，浏览器仍强行解析为 PDF，导致白屏或乱码，而非显示 fallback - 移动端（iOS Safari、微信 WebView）根本无视 fallback 内容：它们优先调起系统 PDF 查看器，
<p></p>永远不渲染
onerror 和 onload 在 object 上基本无效
这两个事件在 object 标签上**不可靠到接近无用**：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
onerror在 PDF 加载失败（404、CORS、MIME 错误）时几乎从不触发；Network 面板只显示Failed to load resource，控制台无 JS 错误 -
onload只在 DOM 插入完成时触发，不代表 PDF 渲染就绪——你看到白屏、进度条卡住，onload早就执行完了 - Flash/Java 等插件场景下，
onerror和onload更是彻底静默失效，因为 NPAPI 接口已被 Chrome 88+、Firefox 85+、Edge 90+ 彻底移除
真正可控的 fallback 必须绕开 object 的缺陷
别把容错希望全押在 object 的子内容上。更实际的做法是分层控制：
立即学习“前端免费学习笔记（深入）”；
- 服务端确保 PDF 响应头严格为
Content-Type: application/pdf，Nginx/Apache 配置 MIME 类型，避免text/plain冒充 - 前端用
<iframe src="report.pdf"></iframe>替代<object></object>：它支持onload/onerror，行为稳定，iOS Safari 也认，且不依赖type校验 - 需要降级链（如 PDF → SVG → PNG → 文字说明），就用 JS 检测容器高度或宽高比是否为 0，再手动切换内容，而不是依赖
object自动 fallback - 若必须用
object，fallback 内容必须是合法 HTML 元素（<p></p>、<div>），不能是注释、纯文本或 <code><script></script>最常被忽略的一点：PDF fallback 是否生效，取决于服务端是否返回了 404、CORS 阻止、
Content-Type不匹配、或加载超时——这些状态object标签本身无法感知，也无法由前端代码主动探测。所谓“兼容异常”，本质是放弃对object的信任，改用更底层、更可测的机制来兜底。
