直接用<iframe>最省事但常失败，因PDF资源或服务端配置问题；白屏多因跨域未配CORS或file://协议；iOS/Safari强制下载；Android/旧Chrome仅显示第一页；URL参数如#page=2跨浏览器兼容性差；<object>/<embed>备用内容基本不生效；需pdf.js的三大信号：跨域CDN无法配CORS、需iOS全页预览、需高级交互功能；部署pdf.js易卡在workerSrc未设、大文件未启流式加载、中文乱码因服务端缺font/woff2 MIME类型；禁用fetch+Blob方案，因其易损坏二进制流、Safari渲染不稳定、大文件阻塞主线程且未解决同源问题；真正难点在于厘清PDF来源、响应头控制权及目标设备。
直接用 <iframe> 最省事，但多数“嵌入失败”不是代码写错，而是 PDF 资源本身或服务端配置没到位。
为什么 <iframe src="xxx.pdf"> 有时白屏、有时下载、有时只显示第一页
这取决于浏览器调用的底层渲染器和当前环境限制：
-
<iframe>不是 HTML 原生渲染 PDF，它只是把控制权交给浏览器内置查看器（Chrome/Edge 用 PDFium，Firefox 默认用 pdf.js，Safari 在 iOS 上几乎不渲染） - 白屏：常见于跨域 PDF 且服务端没返回
Access-Control-Allow-Origin: *；开发时用file://协议打开 HTML 也会白屏（安全策略拦截） - 强制下载：iOS Safari 对
<iframe>中的 PDF 永远不预览，只提供下载按钮；macOS Safari 14+ 同样倾向禁用 inline 渲染 - 只显示第一页缩略图：部分 Android WebView 或旧版 Chrome 会 fallback 到缩略图模式，不触发完整渲染
- URL 参数如
#page=2在 Chrome 有效，在 Firefox/Edge 中可能被忽略——这不是 bug，是各实现未对齐标准
<object> 和 <embed> 的 fallback 内容基本不生效
理论上它们支持备用文案，现实中几乎全失效：
-
<object data="doc.pdf" type="application/pdf"><p>不支持？</p></object>—— Chrome/Firefox/Edge 都不会显示<p>，要么渲染 PDF，要么静默失败 -
<embed>是自闭合标签，不接受子节点；<noembed>已被所有现代浏览器忽略 - 在双内核浏览器（如 360、UC）兼容模式下，
type="application/pdf"可能根本不识别，直接跳过 - 移动端对
<object>支持极差，多数触发下载而非预览
必须上 pdf.js 的三个明确信号
当出现以下任一情况，<iframe> 就不再是“够用”，而是“不可用”：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- PDF 来自跨域 CDN（如 AWS S3），且你无法修改其 CORS 配置
- 需要在 iOS 设备上实现全页可滚动预览（不是缩略图，也不是下载）
- 要监听加载完成、获取总页数、跳转指定页、搜索文本、叠加水印或处理加密 PDF
部署 pdf.js 时最容易卡住的三件事：PDFJS.workerSrc 必须显式赋值，否则控制台报 Failed to load worker；大文件要设 PDFJS.disableStream = false 启用流式加载；中文乱码大概率是服务端没返回 font/woff2 MIME 类型，不是 JS 代码问题。
不要自己拼接 blob URL 或用 fetch 中转 PDF
看到 “用 fetch 请求 PDF → 转 Blob → URL.createObjectURL → 给 <iframe>” 的方案就停手：
- 二进制流在转换过程中容易损坏（尤其 gzip 压缩未解压、响应体截断）
- Safari 对 blob URL 渲染 PDF 支持不稳定，常为空白画布
- 大文件会阻塞主线程，
new Blob([arrayBuffer])可能导致 UI 卡死 - 该方式绕不过同源限制，反而增加出错环节——不如直接配好 CORS 或切到
pdf.js
真正难的从来不是“怎么写那几行 HTML”，而是搞清 PDF 文件从哪来、谁控制响应头、目标用户用什么设备访问——这些决定了你第一行该敲 <iframe> 还是 pdfjsLib.getDocument()。
