object标签当前仅适用于PDF嵌入、SVG图表及旧系统交互文档三类场景；PDF嵌入须满足data指向可访问PDF路径、type为"application/pdf"、服务端响应头含Content-Type: application/pdf，否则将下载或白屏。
object 标签现在只在三类场景里还值得用：PDF 嵌入、SVG 图表、旧系统导出的交互文档。其他情况——图片用 <img>，音视频用 <video> 或 <audio>，通用内容隔离用 <iframe>。
PDF 嵌入必须满足的硬性条件
失败不是因为标签写错，而是服务端或路径配置不匹配：
-
data必须指向可访问的 PDF 文件（如"./docs/report.pdf"），且服务器响应头必须为Content-Type: application/pdf；否则 Chrome/Firefox 会直接下载或白屏 -
type必须是"application/pdf"，写成"pdf"、"text/pdf"或留空，都会触发 fallback - 加
typemustmatch属性可强制校验响应头与type是否一致，避免“返回 HTML 却当 PDF 渲染”的错位 - 本地开发时用
file://协议，Firefox 可能忽略type、只按文件后缀判断；建议统一用http://localhost启服务预览
fallback 内容为什么经常不显示
浏览器只在明确判定加载失败时才渲染内部内容，不是“没显示就降级”：
-
data指向 404 路径、CORS 阻止、或file://协议下被拒绝（必须走 HTTP(S) 服务） -
type和响应头Content-Type不匹配，且加了typemustmatch - fallback 内容不是有效 HTML 子节点：纯文本、注释、空格、
<script>都不算；必须是<p>、<img>或嵌套的另一个<object> - 写了
type却没写data，或反过来——两者至少要有一个，但只写type会导致空白区域
移动端和现代浏览器对 object 的实际处理逻辑
它根本不是“嵌 PDF 的标准方式”，而是个历史遗留容器：
立即学习“前端免费学习笔记（深入）”；
-
<object>无法可靠监听 PDF 加载状态：onload或load事件只在 DOM 插入完成时触发，不等 PDF 渲染完毕；你看到白屏、进度条卡住、滚动失效时，onload早执行完了 - 所有主流浏览器都不支持
contentDocument访问 PDF 内容，Safari 更是直接返回null或抛SecurityError - iOS Safari、微信内置浏览器、QQ 浏览器等几乎永远不显示 fallback 文本；它们要么调起系统 PDF 应用，要么静默失败，控制台也不报错
- 真正需要页码跳转、文本搜索、高亮关键字等功能时，
<object>完全没 API；#page=5参数在data里写进去，iOS Safari 和部分安卓 WebView 会忽略
最常被忽略的一点：PDF 嵌入的成败，80% 取决于服务端响应头是否正确，而不是前端怎么写 object 标签。很多团队花一周调试 HTML，最后发现是 Nginx 没配 types { application/pdf pdf; } 或后端没设 Content-Type。
