最简单嵌入PDF的方式是，需确保路径可访问且符合同源策略或配置CORS；优先选而非
用 <iframe></iframe> 嵌 PDF 最简单，但注意路径和跨域
直接显示 PDF 最常用、兼容性最好的方式就是 <iframe></iframe>。它不依赖 JS，老浏览器也支持，但必须确保 PDF 路径可访问。
常见错误现象：Failed to load resource: the server responded with a status of 404 (Not Found) 或空白 iframe —— 多半是路径写错，或 PDF 文件没部署到 Web 服务器的静态资源目录下。
- PDF 路径必须是相对 URL（如
"./docs/manual.pdf"）或绝对 URL（如"https://example.com/files/report.pdf"），不能是本地文件路径"file:///..." - 如果 PDF 在不同域名下（比如从
https://a.com加载https://b.com/file.pdf），对方服务器必须返回Access-Control-Allow-Origin头，否则 Chrome 会静默失败（无报错，只空白） - 建议加
width和height属性，避免默认高度太小导致只能看到顶部几行
示例：
<iframe src="./report.pdf" width="100%" height="600px" frameborder="0"></iframe>
embed 和 object 标签行为不一致，优先选 embed
<embed></embed> 是最轻量的嵌入方式，现代浏览器基本都支持；<object></object> 理论上更标准，但实际中容易触发 fallback 内容（比如显示“无法加载插件”），尤其在 Chrome 80+ 后对 PDF 插件支持已移除。
立即学习“前端免费学习笔记（深入）”；
使用场景：需要最小化 HTML 体积，或配合 JS 动态切换 PDF 时，<embed></embed> 更可控。
-
<embed></embed>不支持onload事件，没法监听加载完成；<object></object>可以，但可靠性差 - 两者都受同源策略限制，跨域 PDF 若未配 CORS，同样白屏
- 部分旧版 Safari 对
<embed></embed>的type="application/pdf"属性敏感，建议显式加上
示例：
<embed src="guide.pdf" type="application/pdf" width="100%" height="600px" />
移动端 PDF 缩放和滚动体验差？加 viewport 和 CSS 控制
在 iOS Safari 或 Android Chrome 中，<iframe></iframe> 里的 PDF 经常无法双指缩放，或滚动卡顿——这不是 PDF 本身问题，而是容器未适配视口行为。
性能影响：不加控制时，浏览器可能把整个 PDF 渲染为一张大图，内存占用高，滑动掉帧。
- 给
<iframe></iframe>外层加一个带overflow: auto的<div>，并设 <code>-webkit-overflow-scrolling: touch（iOS 必须） - HTML
中确保有 viewport meta：<meta name="viewport" content="width=device-width, initial-scale=1"> - 避免给
<iframe></iframe>设固定像素宽高（如width="800"），改用百分比或vw单位 - 延迟加载：用
data-src存地址，JS 滚动到可视区后再赋值给src（注意：<iframe></iframe>没有原生loading="lazy"支持） - 服务端压缩 PDF：用
qpdf或ghostscript降低图像质量，10MB 的扫描件常能压到 1–2MB - 考虑替代方案：纯文字 PDF 改用 HTML 渲染（如用
pdf.js解析后生成 DOM），交互和 SEO 都更好
PDF 文件太大卡住页面？别让它阻塞 HTML 解析
PDF 加载是同步阻塞的：如果放在 顶部，浏览器会等 PDF header 下载完才继续解析后续 HTML，首屏变慢。
容易踩的坑：把 <iframe src="big.pdf"></iframe> 放在页首，结果用户等 3 秒才看到标题和导航。
复杂点在于：PDF 不是图片，不是字体，也不是普通资源——它既是文档又是应用。浏览器内建 PDF 查看器的行为（比如缩放、打印、搜索）完全不可控，任何样式覆盖或事件拦截都无效。这点很多人一开始没意识到。
