object标签仅适用于pdf和svg：pdf需严格匹配type与content-type，移动端fallback失效；svg支持脚本操作但需同源；其他场景已淘汰。
object 标签在现代前端中已大幅退场，仅剩 PDF 和 SVG 两类内容还值得用它——其他场景（Flash、Java、音视频）基本失效。硬要用 object 做兼容，不是调参数能救的，而是得先确认：你真需要它吗？
PDF 嵌入时 type 和 data 必须严格匹配
浏览器对 object 渲染 PDF 的判定非常机械：只看两个东西是否对得上——data 指向的资源，和服务端返回的 Content-Type 响应头。哪怕只差一个字符，比如服务端返回 text/plain 或 application/octet-stream，Chrome/Firefox 就会直接下载或留白，不渲染也不报错。
-
type必须写成"application/pdf"，写成"pdf"、"text/pdf"或留空，都会跳过内建 PDF 渲染器，直接 fallback - 本地开发用
file://协议时，Firefox 可能忽略type、只按文件后缀判断；建议用http://localhost启服务预览 - 加
typemustmatch属性可强制校验，避免“返回 HTML 却当 PDF 渲染”的错位（例如 Nginx 配置错误返回 404 页面）
移动端 fallback 几乎不触发，别信
标签
写 <object data="a.pdf" type="application/pdf"><p>请下载</p></object> 在 iOS Safari、微信内置浏览器、QQ 浏览器里，<p></p> 内容几乎从不显示。它们要么唤起系统 PDF 应用，要么静默失败，连控制台都不报错。
- 原因不是代码写错，而是现代浏览器把
type="application/pdf"当作“交由系统处理”的信号，绕过了 HTML fallback 流程 - 检测是否 fallback 生效，不能靠视觉判断，得用 JS 查
object.offsetHeight === 0或监听error事件（但该事件在 PDF 加载失败时也常不触发） - 真正可靠的降级方案是：先用 JS 检测 PDF MIME 支持（如
document.createElement('object').canPlayType('application/pdf')），再决定渲染object还是iframe或下载链接
不要试图监听 onload 或访问 contentDocument
object.onload 或 addEventListener('load', ...) 在 PDF 场景下毫无意义。它只在 DOM 节点插入完成时触发，远早于 PDF 渲染就绪——你看到白屏、进度条卡住、页面滚动失效时，onload 早就执行完了。
-
object.contentDocument在所有主流浏览器中都会返回null或抛SecurityError，Safari 更是直接拒绝访问 - 想获取页数、跳转到某页、高亮文本？
object不提供任何 API；这些能力必须靠pdf.js或iframe+ postMessage 通信实现 -
data值含中文或特殊字符（如report.pdf?name=张三）会导致请求发不出，且 fallback 内容也不渲染——URL 必须用encodeURIComponent()编码
SVG 是 object 少数仍可控的场景
object 加载 SVG 时行为比 PDF 稳定得多：支持 onload（等 SVG 文档加载完成）、可访问 contentDocument、支持 CSS 控制样式、允许 JS 操作内部 DOM。
- 必须设
type="image/svg+xml"，否则部分浏览器（如旧版 Edge）会当成普通图片处理，失去交互能力 -
data指向的 SVG 文件需同源，否则contentDocument访问受限；跨域需服务端配Access-Control-Allow-Origin - 相比
<img src="x.svg">，object的优势在于可脚本化操作 SVG 内部元素，但代价是多一次 HTTP 请求（img可缓存复用）
真正麻烦的从来不是怎么写 object，而是它不暴露状态、不反馈失败、不兼容移动端、不支持脚本干预——这些限制不是配置能绕开的，是浏览器主动放弃维护的结果。如果你正在调试一个卡在白屏的 PDF object，优先检查服务端响应头和路径编码，而不是反复改 width 或加 param。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
