embed基本失效，object是唯一勉强可用的兼容方案但需满足data、type、fallback及宽高四要素；2026年PDF嵌入应优先选用iframe，因其支持页面跳转、懒加载且移动端稳定。
embed 和 object 都已不是现代 Web 的推荐方案，但如果你必须嵌入 PDF 或遗留内容，object 是唯一还能凑合用的，embed 基本等于摆设。
为什么 embed 在 PDF/Flash 场景下常为空白或静默失败
embed 标签不校验 type、不协商 MIME 类型、也不提供 fallback 路径。浏览器只看文件扩展名或响应头，出错就留白：
- Chrome 88+ 彻底移除 NPAPI 插件支持 →
embed加载application/x-shockwave-flash直接静默失败 - Safari 在 iOS/iPadOS WebView 中依赖 QuickLook 插件，
embed渲染 PDF 常返回空框 - 安卓微信 X5 内核会拦截
embed的src请求，甚至不发 HTTP 请求 -
embed是自闭合标签，无法嵌套<p>等 fallback 内容，用户得不到任何提示
object 能用的三个硬性条件
object 不是“写了就能渲染”，它必须同时满足以下三点，缺一不可：
-
data属性必须指向可访问的 URL（如doc.pdf），且服务端返回正确的Content-Type（PDF 必须是application/pdf） -
type必须精确匹配 MIME 类型（text/pdf或application/x-pdf会导致 Firefox/Safari 完全跳过） - 标签内部必须包含可渲染的 fallback 内容，例如：
<p>您的浏览器不支持 PDF 预览，请点击下载</p> - 必须设置
width和height（哪怕只是height="600px"），Chrome 缺失时会渲染为 0×0 区域
嵌套 object + embed 的真实作用与风险
这种写法不是为了“增强兼容性”，而是应对 IE9–11 或 Safari ≤5.1 这类极少数遗留系统的妥协策略：
立即学习“前端免费学习笔记（深入）”；
- IE 忽略内部
embed，只走object路径；Chrome/Firefox 则忽略object的classid，fallback 到embed - 若
object的data和embed的src指向不同地址，可能触发两次 HTTP 请求（PDF 场景下明显浪费带宽） -
param标签仍需保留（如<param name="wmode" value="transparent">），虽然 HTML5 中已无实际作用，但旧系统依赖它传参
2026 年真正该用什么？iframe 才是 PDF 嵌入的现实选择
iframe 不仅支持 #page=3 页面跳转、loading="lazy" 懒加载，还在移动端稳定：
- PDF 文件本身是否支持 Web 预览同样关键：不能加密、不能含 JS、不能强制下载头
- 服务端需返回
Content-Type: application/pdf，否则 Chrome 会直接下载而非内嵌 - 不要用
object或embed包裹iframe——它们互不兼容，只会增加不可控行为
复杂点不在怎么写标签，而在服务端配置和 PDF 文件本身的限制；这些细节漏掉，再标准的 HTML 也白搭。
