object 标签嵌入 pdf 在现代浏览器中兼容性差，易白屏或下载；仅适用于服务端可控、需 type 校验与原生 fallback 的内网场景，fallback 仅在加载失败（404/cors/content-type 不匹配）时触发，且受 typemustmatch、响应头、路径编码、移动端限制等多重影响。
object 标签嵌入 PDF 在现代浏览器中不是“能用就行”，而是“稍有偏差就白屏或下载”。它只在需要严格 type 校验、原生 fallback 语义、且服务端完全可控的场景下值得用——比如企业内网文档系统，或需配合 typemustmatch 做安全兜底的 PDF 预览页。
为什么 object 的 fallback 经常不显示
浏览器只在明确判定加载失败（如 404、CORS 拒绝、Content-Type 与 type 不匹配）时才渲染内部内容。常见失效原因：
-
data指向相对路径但服务器未正确返回 PDF（例如返回 404 HTML 页面，而非 PDF 文件） - 服务端响应头是
Content-Type: text/plain或缺失，而你写了type="application/pdf"且加了typemustmatch - 本地开发用
file://协议打开：Firefox 忽略type，Safari 直接拒绝加载，fallback 永远不触发 - 内部内容不是合法子节点：
<p></p>可以，<div>、<code><script></script>、纯文本或空格都不行data和type必须同时对，且服务端要配合写错任意一环，
object就会静默降级或触发下载。关键点：-
type必须是"application/pdf"—— 写成"pdf"、"application/x-pdf"或留空，Chrome/Firefox 都不认 -
dataURL 必须可访问，且服务端响应头必须为Content-Type: application/pdf - URL 含中文或空格（如
report.pdf?name=张三）必须encodeURIComponent编码，否则请求发不出，fallback 也不渲染 - 加
typemustmatch属性可强制校验响应头，避免“返回 HTML 却当 PDF 渲染”的安全错位
移动端和微信内置浏览器基本不走
objectfallback 流程iOS Safari、微信/QQ 内置浏览器对
type="application/pdf"的处理逻辑已转向“交由系统应用打开”或“静默下载”，<p></p>fallback 几乎从不显示。更现实的做法：- 别依赖
object的 fallback 文案做兜底，改用 JS 检测：监听error事件（虽不总触发），或定时检查offsetHeight === 0 - 对移动端用户，直接提供下载链接 +
<iframe src="xxx.pdf"></iframe>双路并行，iframe在 iOS 15+ 和安卓 WebView 中渲染更稳 - 如果必须用
object，去掉type属性反而可能让部分安卓浏览器回退到下载提示（比白屏强）
真正麻烦的是验证，不是写法
同一段
<object data="doc.pdf" type="application/pdf"><p>下载</p></object>，在 Mac Chrome 可能正常，在 Windows Edge 白屏，在 iOS 微信里直接跳转下载。问题往往不在 HTML，而在：- PDF 文件是否真被服务器以
application/pdf类型返回（用 DevTools → Network → Headers 看） - 路径是否跨域？是否被 CSP
frame-ancestors或object-src拦截？ - Safari 16+ 要求显式设置
width/height才启用内建查看器，Chrome 却不需要
没跑通前，先用
http://localhost启个服务测，别信file://下的任何表现。 -
