object标签的fallback文字仅在特定失败时显示：HTTP错误码、Content-Type不匹配、CORS阻止或file://协议被拒；其他如路径错误、渲染卡死、空响应等均不触发。
object 标签的 fallback 文字不是“写进去就显示”，它只在特定失败路径下才渲染，多数白屏或下载行为根本不会触发它。
fallback 什么情况下会显示
浏览器只在以下任一条件满足时，才渲染 object 内部的 HTML 内容（即 fallback）：
-
data指向的 URL 返回 HTTP 错误状态码（如404、500、403） - 服务端响应头中的
Content-Type与type属性值不匹配（例如type="application/pdf"但服务器返回text/html） - CORS 阻止请求完成（此时控制台报错，但 fallback 可能仍不显示——Firefox 较守规范，Chrome 有时静默）
- 使用
file://协议本地打开，且浏览器拒绝加载（如 Firefox 对type校验宽松，但 Chrome 直接跳过）
注意：data 路径拼错（如 "./pdfs/report.pdf" 实际在 /static/files/）、PDF 渲染卡死、移动端调起系统阅读器、或服务端返回空响应体，这些都不会触发 fallback。
fallback 内容必须是合法 HTML 元素
不能是注释、纯文本、<script> 或空格。只接受可渲染的内联或块级元素：
立即学习“前端免费学习笔记（深入）”；
- ✅ 可行：
<p>PDF 加载失败，请点击下载</p>、<div><a href="report.pdf" download>下载 PDF</a></div> - ❌ 无效：
<!-- 备用提示 -->、PDF 加载失败（无标签包裹）、<noembed></noembed>（已废弃）
嵌套另一个 object 是可行的降级链，比如先试 SVG，再 fallback 到 PNG，最后文字表格，但每层都依赖自己的 data 和 type 正确。
为什么你写的 fallback 总不出现
常见失效原因：
- 没加
typemustmatch属性：服务端返回 HTML 却被当 PDF 渲染，浏览器认为“类型匹配”，不走 fallback - 移动端（iOS Safari / 微信 WebView）对
type="application/pdf"的处理逻辑是“交由系统打开”，根本不进入 HTML fallback 流程 -
data值含未编码的#或中文（如report.pdf?name=张三），导致请求发不出，控制台可能连Failed to load resource都不报 - 本地开发用
file://协议：Firefox 可能忽略type、只认后缀；Chrome 直接拒绝加载 —— 必须用npx http-server启 HTTP 服务预览
更可靠的 fallback 替代方案
靠 object 自身 fallback 不现实，建议组合 JS 检测：
- 监听
error事件（虽然 PDF 场景下常不触发，但对 404 等有效）：objectEl.addEventListener('error', () => { fallbackEl.style.display = 'block'; }); - 定时检测高度：
if (objectEl.offsetHeight === 0) { ... }，适合 PDF 白屏场景 - 直接弃用
object改用iframe：<iframe src="report.pdf"><p>PDF 加载失败</p></iframe>—— 它的 fallback 行为更稳定，且现代浏览器对src的 PDF 处理优先级更高
真正容易被忽略的是：fallback 是否生效，取决于服务端响应头、网络链路、协议类型这三层，前端无法用 JS 强制触发。写得再全，如果 Nginx 没配 application/pdf MIME 类型，或者路径 404 后返回了 HTML 错误页而非标准 404 状态码，fallback 就永远不出现。
