object标签在现代浏览器中没有插件生命周期，仅对PDF嵌入稳定有效，需同时满足data为HTTP(S)可访问URL、type严格为application/pdf、服务端响应头含Content-Type: application/pdf，否则fallback不触发。
object 标签在现代浏览器中**没有插件生命周期可管理**——它不触发 init、start、destroy 等阶段，也不支持通过 JS 控制插件状态。所谓“容错”，实际只是资源加载失败后的降级切换，且仅对少数类型有效。
为什么 onerror 和 onload 基本不可靠
这两个事件在插件类资源（Flash、Java Applet、ActiveX）上几乎不触发：
-
onerror在 NPAPI/ActiveX 接口被移除后静默失效；Network 面板只显示Failed to load resource，控制台无报错 -
onload仅对同源SVG或极少数 PDF 场景有效，且需渲染就绪才触发，不能代表“加载成功” - 即使
data指向一个真实存在的 PDF，若服务端返回Content-Type: text/html，浏览器会尝试渲染为 HTML 页面，此时既不触发onerror，也不进入 fallback
object 唯一稳定可用的场景：PDF 嵌入
只有 PDF 是当前主流浏览器仍原生支持的 object 使用场景，但必须满足三重硬性条件：
-
data必须是可访问的 HTTP(S) URL（file://协议下多数浏览器拒绝加载） -
type必须严格为application/pdf（写成pdf、text/pdf或留空均无效） - 服务端响应头必须含
Content-Type: application/pdf；Nginx/Apache 未配置 MIME 类型会导致空白或下载 - 加
typemustmatch属性可强制校验响应头与type一致，避免 HTML 冒充 PDF 渲染
示例：
立即学习“前端免费学习笔记（深入）”；
<object data="report.pdf" type="application/pdf" typemustmatch style="width:100%; height:600px;"> <p>PDF 加载失败，请点击下载。</p> </object>
fallback 内容为何经常不显示
fallback 不是“备用文案”，而是浏览器解析失败后渲染的合法子节点。常见失效原因：
- 写成注释（
<!-- 备用提示 -->）、纯文本（如直接写“加载失败”）或空格，这些不会被当作可渲染内容 -
<param>标签放在object内部，但它不参与 fallback 流程，仅向已存在的插件传参——而插件早已不存在 - 资源加载成功但渲染为空白（如 PDF 加密、跨域 iframe 嵌套、权限受限），此时 fallback 不会自动触发
- 嵌套了另一个
object但其data同样不可达，导致多级 fallback 全部跳过
真正可控的容错路径不在前端标签写法，而在服务端响应一致性、路径可访问性、以及用 iframe 替代复杂需求——object 的“多层降级”能力，在现实中极易因一个 MIME 错误或协议限制而全线失效。
