object标签嵌入pdf时type属性必须为application/pdf，且须与服务端content-type响应头完全一致；data url含中文或参数需encodeuricomponent编码；移动端fallback无效，需js检测或改用iframe/pdf.js。
object标签嵌入PDF时type属性必须写成application/pdf
写成pdf、text/pdf、application/x-pdf或留空，Firefox 和 Safari 都会跳过渲染直接触发 fallback 或下载。Chrome 虽然有时能“猜对”，但一旦服务端响应头不匹配，就立刻白屏。
常见错误现象：页面显示 fallback 文字，但控制台无报错；或 PDF 文件明明存在，却始终下载而非预览。
-
type必须与服务端返回的Content-Type响应头完全一致，大小写敏感 - 本地开发用
file://协议时，Firefox 会忽略type、只看文件后缀，建议改用http://localhost启动服务验证 - 加
typemustmatch属性可强制校验，避免后端返回 HTML 却被当 PDF 渲染（比如 404 页面）
data URL含中文或查询参数时必须encodeURIComponent编码
像report.pdf?name=张三&token=abc+123这种 URL，未编码会导致net::ERR_INVALID_URL，object 标签静默失败，fallback 也不显示——连<p></p>都收不到渲染机会。
使用场景：PDF 来自后端动态生成接口，带用户 ID、时间戳、签名等参数。
- 前端拼接前必须对整个 query string 做
encodeURIComponent，不要只编单个值 - 服务端若返回重定向（如 302 到带参 URL），也要确保重定向目标已编码
- 测试时可用
console.log(decodeURIComponent(dataValue))反向验证是否过度编码
移动端 fallback 几乎无效，别依赖<p></p>子节点兜底
iOS Safari、微信内置浏览器、QQ 浏览器等，遇到type="application/pdf"会直接交由系统 PDF 查看器或静默失败，<object></object>内部的<p></p>内容从不渲染，也几乎不触发error事件。
这意味着你写的“请下载”提示，在真实用户手机上大概率根本看不到。
- 想真正兜底，得靠 JS 检测：
object.offsetHeight === 0或定时轮询object.contentDocument是否为 null - 更可靠的做法是放弃 object，在支持 PDF 的浏览器中用
<iframe></iframe>，不支持时降级为带download属性的<a></a>链接 -
<noembed></noembed>已被所有现代浏览器忽略，别再写
object无法监听加载完成，页码跳转和高亮都不可行
onload事件在 DOM 插入后立即触发，不代表 PDF 渲染完毕；contentDocument在所有主流浏览器中返回null或抛SecurityError；#page=5这类 URL 参数在 iOS Safari 和多数安卓 WebView 中被无视。
如果你需要知道“PDF 真正加载好了”“当前显示第几页”“搜索文本并高亮”，<object></object>不是入口，它根本不暴露这些能力。
- 页码控制只能靠
data="doc.pdf#page=3"，但兼容性差，iOS 下基本失效 - 无法通过 JS 获取页数、缩略图、文本层，也无法注入 CSS 或监听滚动
- 真要交互能力，必须换 pdf.js ——
<object></object>只适合静态只读展示，且仅限桌面端可控环境
真正麻烦的不是怎么写<object></object>，而是它看起来能用，实际上在移动端、跨域、带参、需交互等常见场景里，几乎处处受限。如果项目要求稳定预览或任何用户操作，优先考虑<iframe></iframe>或 pdf.js，把<object></object>留给纯内网、固定路径、仅 Chrome/Firefox 桌面访问的极简场景。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
