object标签fallback常不显示，因其仅在明确加载失败（404/cors/file://拒绝/content-type不匹配）时触发，非“未显示即降级”；失效主因包括data路径错误、响应头mime不匹配、fallback非合法html元素（如注释或纯文本），且现代浏览器中pdf嵌入需同时满足data为http(s) url、type为"application/pdf"、服务端返回content-type: application/pdf三重条件。
object标签的fallback为何经常不显示
fallback内容只在明确加载失败时才渲染，不是“没显示就降级”。常见失效场景包括：data指向404路径、CORS阻止、file://协议下被浏览器拒绝（必须用http://或https://服务预览）、type与服务端Content-Type响应头不匹配。写成注释<!-- 备用提示 -->或纯文本（如直接写“加载失败”）也不会触发渲染——fallback必须是合法HTML元素，比如<p>PDF 加载失败</p>。
PDF嵌入必须满足的三重硬性条件
现代浏览器中object唯一稳定可用的场景是PDF嵌入，但需同时满足：
• data必须是可访问的HTTP(S) URL（./report.pdf在本地开发时需通过npx http-server启动服务，不能直接双击HTML）
• type必须严格为"application/pdf"（写成"pdf"、"text/pdf"或留空均无效）
• 服务端响应头必须含Content-Type: application/pdf；Nginx/Apache未配置MIME类型会导致空白或强制下载
加typemustmatch属性可强制校验MIME类型匹配，避免HTML内容被冒充PDF渲染
onerror和onload在object上基本不可靠
onerror和onload对object几乎不起作用：
• onerror在NPAPI/ActiveX接口移除后静默失效，控制台只显示Failed to load resource，不进JS回调
• onload仅在极少数同源PDF或SVG场景下触发，且仅代表DOM插入完成，不代表PDF渲染就绪或内容可读
• 即使data指向真实PDF，若服务端返回Content-Type: text/html，浏览器会尝试渲染为HTML页面，既不触发onerror，也不进入fallback
别试图用contentDocument访问PDF内容——所有主流浏览器都会返回null或抛SecurityError
真正可控的容错路径不在标签写法，而在替代与检测
硬扛object写法无法解决根本问题，更实际的做法是：
• PDF优先改用<iframe src="report.pdf"></iframe>：不依赖type、不走插件协商、加载更稳、移动端fallback也更可靠
• 需要交互控制（如跳页、搜索）时，必须用pdf.js，它提供完整API，object完全不暴露这类能力
• 若仍需保留object，fallback检测只能靠JS间接判断：监听load后检查元素高度是否为0、定时轮询offsetHeight、或用fetch提前探测PDF URL是否返回200 + 正确Content-Type
• 所有“多层降级”设计（如嵌套object）在现实中极易因一个MIME错误或路径拼错而全链路失效——这层脆弱性常被忽略
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
