iframe比object更适配PDF嵌入，因现代浏览器优先通过iframe渲染PDF，不依赖type校验、支持全屏与手势缩放，且加载更稳定；object需严格匹配MIME类型并配置fallback，易在移动端失效。
直接用 <iframe></iframe>，别碰 <object></object> —— 除非你明确需要 fallback 降级逻辑或嵌入 PDF 以外的旧式插件内容。
为什么 iframe 比 object 更适合嵌 PDF
现代浏览器对 PDF 的内嵌支持集中在 <iframe></iframe> 上：Chrome、Edge、Firefox 和 Safari（iOS 15+）都把它当作第一优先级渲染路径。它不依赖 type 属性，不校验 MIME 类型，也不触发插件协商流程，所以更少出错、更快加载。
-
<object data="doc.pdf" type="application/pdf"></object>在 iOS Safari 和部分安卓 WebView 中，type反而会让浏览器放弃内置查看器，跳转到系统应用或直接下载 -
<iframe src="doc.pdf"></iframe>完全绕过type判断，由浏览器自动协商，行为更可预期 -
<iframe></iframe>支持allow="fullscreen"，能启用原生全屏按钮；<object></object>即使加了<param name="allowFullScreen" value="true">，在 Chrome/Firefox 中也基本无效 - 移动端滚动和双指缩放，在
<iframe></iframe>中是默认开启的；<object></object>需要手动包裹div+overflow: auto，还常因高度塌陷导致手势失效
iframe 嵌 PDF 必须配的三件事
写对 src 不等于能显示。PDF 要真正“打开”，得同时满足网络、协议、响应头三个条件。
-
src必须是完整可访问的 HTTP/HTTPS URL，不能是./doc.pdf或file://—— 后者在所有现代浏览器中被静默拦截，且无控制台提示 - 服务器必须返回
Content-Type: application/pdf，否则浏览器当普通二进制流处理，直接下载 - 若 PDF 在跨域 CDN（如 S3、Cloudflare R2），服务端必须返回
Access-Control-Allow-Origin头，否则请求被 CORB 拦截，页面白屏且 Network 面板显示状态码为 0
快速验证：在终端运行 curl -I https://your.site/doc.pdf，确认响应头含 Content-Type: application/pdf 和 Accept-Ranges: bytes（后者决定拖动进度条是否卡顿）。
立即学习“前端免费学习笔记（深入）”；
object 标签真要用，这些坑躲不开
如果你非得用 <object></object>（比如要兼容老系统、或需要多层 fallback），以下几点不检查，fallback 就永远不会出现。
-
data属性不能为空、不能是javascript:伪协议、不能含未编码中文（如report.pdf?name=张三），否则浏览器连请求都不发，内部<p></p>内容也压根不会渲染 -
type="application/pdf"必须严格匹配，写成pdf、text/pdf或留空，Chrome/Firefox 都会忽略并直接走 fallback - fallback 内容必须是合法 HTML 子节点：
<p>请下载</p>可以，<!-- fallback -->或纯文本不行，<script></script>更不会执行 - 本地开发时，
file://协议下<object data="xxx.pdf"></object>必定失败 —— 必须起 HTTP 服务，例如python3 -m http.server
最常被忽略的一点：PDF 加载慢、翻页卡、缩放失灵，90% 不是前端代码问题，而是服务器没返回 Accept-Ranges: bytes。这个头决定了浏览器能不能按需拉取 PDF 的某一段字节 —— 没它，用户拖动进度条就得等整份文件下载完才响应。
