object标签不推荐用于pdf加载，因其onload仅表示dom插入、不保证渲染完成，移动端fallback失效，url未编码易出错，且无法获取渲染状态；应优先使用iframe或pdf.js。
object 标签在现代浏览器中已不推荐用于 PDF 加载——它看似标准，实则不可靠，尤其在移动端和加载控制上几乎失效。直接用 iframe 或 pdf.js 更实际。
为什么 object 的 onload 事件根本不能判断 PDF 是否渲染完成
浏览器对 object 元素触发的 load 事件，仅表示 DOM 节点已插入文档，并不等待 PDF 文件下载、解析或渲染结束。你看到白屏、进度条卡住、甚至页面滚动异常时，load 早已执行完毕。
-
object不暴露任何 PDF 渲染状态（如页数、缩略图就绪、文本可选中） -
document.querySelector('object').contentDocument在 Chrome/Firefox/Safari 中一律返回null或抛出SecurityError - 试图监听
error事件捕获加载失败？该事件在多数 PDF 加载失败场景下根本不触发
data 属性含中文或查询参数时，请求常静默失败
URL 中未编码的空格、中文、特殊符号（如 report.pdf?name=张三&token=abc+123）会导致 net::ERR_INVALID_URL，且 fallback 内容（<p></p>）也不会显示。
- 必须对整个 URL 调用
encodeURIComponent()，但注意：只编码参数值，不要全量编码路径部分 - 推荐服务端生成带 token 的 PDF URL 时，统一做
urlencoding，前端只拼接干净的data值 - 纯
100%宽高在 Flex/Grid 容器中可能塌陷，应设为width="800px"或width="100vw"等带单位值
移动端 fallback 几乎从不生效，别依赖 <p></p> 子节点
iOS Safari、微信内置浏览器、QQ 浏览器等会直接调起系统 PDF 应用或静默失败，<object><p>请下载</p></object> 中的 <p></p> 永远不会显示。
- 原因在于现代移动端浏览器将
type="application/pdf"视为“交由系统处理”信号，跳过 HTML fallback 流程 - 删掉
type属性也无济于事——它们仍按协议头或文件扩展名判定并降级为下载链接 - 真要兜底，得用 JS 主动检测：
object.offsetHeight === 0或轮询getBoundingClientRect()，再配合超时 fallback
比起 object，iframe 是更稳的降级选择
iframe 绕过了插件协商与 MIME 类型校验机制，在 Chrome/Firefox/Edge/Safari（iOS 15+）中均作为第一顺位渲染路径，且天然支持 loading="lazy" 和 allow="fullscreen"。
-
iframe不需要type属性，src指向 PDF 即可触发内置阅读器 - 它能响应
load事件（虽然仍不代表 PDF 渲染完成，但至少比object更接近真实加载终点） - 若需页码跳转，
src="doc.pdf#page=5"在桌面端稳定生效；移动端仍可能忽略，但兼容性远高于object的data参数
真正需要交互控制（搜索、高亮、页码跳转、缩放同步）或保障移动端体验时，object 就不该出现在方案里——它的设计初衷是通用插件容器，不是 PDF 预览组件。现在连 PDFObject 这类封装库，底层也早默认回退到 iframe 或直接集成 pdf.js。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
