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>都收不到渲染机会。
使用场景：PDF 来自后端动态生成接口，带用户 ID、时间戳、签名等参数。
立即学习“前端免费学习笔记（深入）”；
- 前端拼接前必须对整个 query string 做
encodeURIComponent，不要只编单个值 - 服务端若返回重定向（如 302 到带参 URL），也要确保重定向目标已编码
- 测试时可用
console.log(decodeURIComponent(dataValue))反向验证是否过度编码
移动端 fallback 几乎无效，别依赖<p>子节点兜底
iOS Safari、微信内置浏览器、QQ 浏览器等，遇到type="application/pdf"会直接交由系统 PDF 查看器或静默失败，<object>内部的<p>内容从不渲染，也几乎不触发error事件。
这意味着你写的“请下载”提示，在真实用户手机上大概率根本看不到。
- 想真正兜底，得靠 JS 检测：
object.offsetHeight === 0或定时轮询object.contentDocument是否为 null - 更可靠的做法是放弃 object，在支持 PDF 的浏览器中用
<iframe>，不支持时降级为带download属性的<a>链接 -
<noembed>已被所有现代浏览器忽略，别再写
object无法监听加载完成，页码跳转和高亮都不可行
onload事件在 DOM 插入后立即触发，不代表 PDF 渲染完毕；contentDocument在所有主流浏览器中返回null或抛SecurityError；#page=5这类 URL 参数在 iOS Safari 和多数安卓 WebView 中被无视。
如果你需要知道“PDF 真正加载好了”“当前显示第几页”“搜索文本并高亮”，<object>不是入口，它根本不暴露这些能力。
- 页码控制只能靠
data="doc.pdf#page=3"，但兼容性差，iOS 下基本失效 - 无法通过 JS 获取页数、缩略图、文本层，也无法注入 CSS 或监听滚动
- 真要交互能力，必须换 pdf.js ——
<object>只适合静态只读展示，且仅限桌面端可控环境
真正麻烦的不是怎么写<object>，而是它看起来能用，实际上在移动端、跨域、带参、需交互等常见场景里，几乎处处受限。如果项目要求稳定预览或任何用户操作，优先考虑<iframe>或 pdf.js，把<object>留给纯内网、固定路径、仅 Chrome/Firefox 桌面访问的极简场景。
