object标签加载PDF失败主因是data路径、type值或服务端Content-Type响应头三者不匹配，而非代码错误；HTTP 200不代表渲染成功，MIME类型不符或file://协议下浏览器会静默白屏，onerror不触发，fallback仅在明确加载失败时显示。
object 标签资源加载失败，90% 不是代码写错，而是路径、响应头或浏览器机制不匹配——它不会报错，只留白；onerror 基本不触发，param 完全无效，fallback 也不一定显示。
为什么 Network 面板看到 200 却还是白屏
HTTP 状态码为 200 只代表请求发出去了、服务器返回了内容，不代表浏览器认可这个内容可渲染。常见原因包括：
-
type="application/pdf"写成"pdf"、"text/pdf"或留空，Chrome/Firefox 直接跳过内嵌逻辑 - 服务端返回的响应头是
Content-Type: text/html或application/octet-stream，哪怕文件真是 PDF，浏览器也会拒绝渲染（加typemustmatch属性可强制校验） - 本地开发用
file://协议打开 HTML，Firefox 会忽略type、只认后缀；Chrome 和 Edge 则直接拒绝加载 PDF - PDF 文件本身损坏、加密或含不支持的特性（如 AES-256 加密），浏览器静默失败，不进
onerror，也不显示 fallback
fallback 内容为何从不出现
fallback 不是“备用提示”，而是浏览器在明确判定加载失败后才渲染的子节点。失效场景很具体：
- 写成纯文本（如直接写“加载失败”）或 HTML 注释（
<!-- 备用 -->），这些都不是合法的可渲染子元素 -
<p>PDF 加载失败</p>是可行的，但<div>在部分旧规范中不被允许，建议用<p>或<span> - 资源请求成功（HTTP 200），但内容不可用（如跨域 iframe 嵌套 PDF、权限受限、iOS Safari 强制调起系统应用），此时 fallback 不触发
- 路径拼错导致 404，但你没在 Network 面板里点开看——很多开发者只扫一眼列表，没注意那个红色请求其实就是
data指向的地址
PDF 场景下该用 object 还是 iframe
对 PDF，iframe 实际比 object 更可靠，不是因为“更现代”，而是绕过了 MIME 类型协商和插件宿主机制：
立即学习“前端免费学习笔记（深入）”；
-
<iframe src="report.pdf" width="100%" height="600"></iframe>在 Chrome/Firefox/Edge/iOS 15+ 上默认启用缩放、手势滚动、全屏按钮（加allow="fullscreen"即可） -
iframe支持onload事件（虽不能判断 PDF 渲染完成，但至少能知道 iframe 节点已就绪） -
object的contentDocument在所有主流浏览器中访问 PDF 时均返回null或抛SecurityError，无法做页跳转、搜索等交互 - 如果必须动态控制 PDF（比如带 token 的 URL），确保
src或data中的中文、空格已用encodeURIComponent()编码，否则 iOS Safari 和部分 WebView 会直接报net::ERR_INVALID_URL
真正该检查的三个硬性条件
别纠结标签写法，先确认这三点是否全部满足：
-
data必须是可访问的 HTTP(S) URL，例如"https://example.com/docs/report.pdf"或"http://localhost:8080/report.pdf"；file://协议在绝大多数现代浏览器中被禁用 -
type必须严格为"application/pdf"，大小写敏感，不能省略引号 - 服务端必须返回
Content-Type: application/pdf响应头；Nginx/Apache 需显式配置 MIME 类型，静态托管平台（如 Vercel、Netlify）通常默认支持，但自建服务常遗漏
这三个条件缺一不可。少一个，object 就不会尝试渲染 PDF，而 fallback 是否出现，取决于失败类型——404 会触发，MIME 不匹配却可能静默白屏，连 fallback 都不给机会。
