onerror和onload在object标签上基本不可用，因现代浏览器已彻底移除npapi/activex接口，object失去执行上下文；onerror静默失效，onload仅对极少数pdf或同源svg“勉强”触发，且不保证渲染就绪。
onerror 在 object 标签上基本不可用——这不是写法问题，是浏览器根本没给它触发机会。
为什么 onerror 和 onload 都不触发
现代浏览器（Chrome 88+、Firefox 85+、Edge 90+、Safari 14+）已彻底移除 NPAPI/ActiveX 插件接口，object 失去执行上下文：
-
onerror事件在 Flash/Java/ActiveX 等插件类资源上静默失效；Network 面板只显示Failed to load resource，控制台无错误、JS 不进入回调 -
onload仅对同源 SVG 或极少数 PDF 场景“勉强”触发，且仅代表 DOM 节点插入完成，不代表 PDF 渲染就绪或可交互 - 即使
data指向真实存在的 PDF，若服务端返回Content-Type: text/html，浏览器会尝试渲染为 HTML，此时既不触发onerror，也不进入 fallback
PDF 嵌入时 fallback 为何经常不显示
fallback 不是“备用文案”，而是浏览器明确判定加载失败后才渲染的子节点。常见失效原因：
- 写成注释
<!-- 备用提示 -->、纯文本（如直接写“加载失败”）或空格——这些不会被当作可渲染内容 -
<param>标签放在object内部，但它不参与 fallback 流程，仅向插件传参（而插件早已不存在） - 资源加载成功但渲染为空白（如 PDF 加密、跨域限制、权限不足），此时 fallback 不会自动触发
- 嵌套了另一个
object但其data同样不可达，导致多级 fallback 全部跳过
真正能落地的容错方案只有两条路
别在 object 上死磕事件监听，改用更可控的替代路径：
- 用
iframe替代：支持稳定onload/onerror，PDF 可直接src="report.pdf"，失败时能可靠捕获并降级 - 用
fetch+ MIME 类型预检：先发 HEAD 请求校验Content-Type: application/pdf和状态码，再决定是否插入object或展示错误提示 - 服务端必须配对：Nginx/Apache 需显式配置
.pdf的 MIME 类型为application/pdf；加typemustmatch属性强制校验响应头与type一致
最常被忽略的一点：本地开发用 file:// 协议时，Firefox 可能忽略 type、只认文件后缀；务必用 npx http-server 启 HTTP 服务验证，否则所有 fallback 行为都不可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
