优先用<iframe>但需配CORS和fallback；要交互控制或iOS/Safari全页预览，必须用pdf.js。因<iframe>依赖浏览器渲染器，存在跨域白屏、iOS强制下载、无法监听事件等问题；<object>/<embed>备用内容基本失效；pdf.js可解决跨域、页码跳转、文本搜索等需求，但需正确配置worker路径、流式加载及字体MIME类型。
直接结论：优先用 <iframe>，但必须配 CORS 和 fallback；要交互控制或支持 iOS/Safari 全页预览，必须上 pdf.js。
为什么 <iframe> 是最常用却最容易翻车的方式
它依赖浏览器内置 PDF 渲染器（Chrome/Edge 用 PDFium，Firefox 默认用 pdf.js），看似一行代码就能跑，但实际踩坑密集：
-
src必须同源，或服务端返回Access-Control-Allow-Origin: *，否则白屏且控制台无错误提示 - iOS Safari 强制下载而非预览（哪怕加了
download属性也无效），仅显示第一页缩略图 - 无法监听加载完成、页数、渲染失败等事件，
onload只表示 iframe 节点加载完，不表示 PDF 渲染就绪 - URL 后加参数如
#page=3&view=FitH在 Chrome 有效，但在 Firefox 或 Edge 中可能被忽略
<object> 和 <embed> 的 fallback 看似友好，实则基本失效
这两个标签理论上支持备用内容（比如“请下载 PDF”提示），但现实是：
-
<object data="doc.pdf" type="application/pdf"><p>不支持？</p></object>—— 备用内容在 Chrome/Firefox/Edge 中几乎从不显示，浏览器直接调用 PDF 查看器或静默失败 -
<embed src="doc.pdf">是自闭合标签，不支持子节点，<noembed>已被现代浏览器完全忽略 - IE 早已淘汰，360/UC 等双内核浏览器在兼容模式下会走旧 Trident 内核，导致
type="application/pdf"不识别 - 移动端（Android Chrome、iOS Safari）对
<object>和<embed>支持极差，多数直接触发下载
什么时候必须用 pdf.js，以及部署时最关键的三件事
当你需要以下任一能力时：pdf.js 不是“可选”，而是唯一可行路径：跨域 PDF、iOS 全页预览、页码跳转、文本选择、水印叠加、加密 PDF 解密、搜索高亮。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
pdf.worker.min.js路径必须显式配置，否则控制台报Failed to load worker—— 在初始化前加PDFJS.workerSrc = "./pdf.worker.min.js"; - 大文件首次加载慢，需启用流式加载：
PDFJS.disableStream = false;（默认为true，会等整个 PDF 下载完才开始解析） - 字体缺失会导致中文乱码，必须确保服务端对
.woff2字体文件返回正确 MIME 类型font/woff2，否则 canvas 渲染空白
移动端和低版本浏览器的兜底策略不能只靠 HTML 标签
纯前端方案在 Android/iOS 上天然受限，真正可用的降级逻辑是服务端配合：
- 检测 User-Agent，对 iOS Safari 直接返回
Content-Disposition: inline; Content-Type: application/pdf响应头，让系统 PDF 预览器接管（比 iframe 更稳） - 对不支持
pdf.js的老旧环境（如 IE11），提供带target="_blank"的<a href="doc.pdf">打开 PDF</a>，避免页面卡死 - 不要试图用 base64 写死 PDF 到
<iframe src="data:...">—— iOS Safari 对 data URL 长度有限制，超 2MB 就截断，渲染失败
真正难的不是“怎么嵌”，而是判断「当前设备+当前 PDF+当前网络」下哪条链路最可靠。标签只是入口，背后是服务端响应头、CDN 缓存策略、字体托管、worker 加载时机这些容易被忽略的细节。
