data属性不合法时浏览器根本不会发起请求，仅当data为合法url且加载成功但无法处理时fallback才生效；type仅参与mime协商，实际渲染取决于服务端content-type响应头。
data 属性不合法时根本不会发起请求
很多人以为写个 data="" 或 data=" " 会触发 fallback，实际浏览器直接跳过——既不发网络请求，也不渲染内部内容。只有当 data 是一个语法合法的 URL（如 data="report.pdf"、data="./charts.svg"）且能被解析为绝对路径时，浏览器才会尝试 fetch。
常见失效写法包括：
-
data="file://local/doc.pdf"：现代浏览器默认拦截，控制台静默，不报错也不 fallback -
data="report.pdf?name=张三"：中文未 URL 编码，部分浏览器截断请求或返回 400，且不触发 fallback -
data="../wrong/path.svg"：相对路径解析失败 → 404 → 此时才可能触发 fallback（前提是响应头没被 CORS 阻断）
type 属性只参与 MIME 协商，不决定是否加载
type 不是“开关”，它只是告诉浏览器“我预期这个资源是什么类型”。真正起效的是服务端返回的 Content-Type 响应头。即使你写了 type="application/pdf"，只要服务器返回 Content-Type: text/html，Chrome 就会把 PDF 当 HTML 渲染，导致白屏或乱码，且不触发 onerror。
关键事实：
-
type写错（比如image/svg而非image/svg+xml）通常不影响 SVG 显示，只要响应头正确 -
type留空或为pdf、text/pdf，PDF 场景下大概率直接跳过内嵌逻辑，退为下载 - 加
typemustmatch属性可强制校验响应头与type一致，避免 HTML 冒充 PDF —— 这是唯一能靠前端约束 MIME 的方式
fallback 只在“加载成功但无法处理”时生效
fallback 不是“data 失败兜底”，而是浏览器明确识别出资源已加载、但当前环境无法渲染时才启用的降级路径。这意味着：
-
data拼错、404、网络中断 → 有可能触发 fallback（取决于响应头是否可读） -
data正确、服务端返回Content-Type: application/octet-stream→ 浏览器判定不可渲染 → fallback 显示 -
data正确、响应头也对，但用户禁用了 PDF 查看器 → fallback 显示 -
data正确、响应头也对，但 PDF 加密或含 JS → 渲染失败，但 fallback 不自动触发（浏览器认为“已加载”，只是内容不可用）
fallback 内容必须是合法 HTML 元素：<p>PDF 加载失败</p> 可行；<!-- 备用提示 -->、纯文本、空格、<script></script> 都无效。
PDF 是当前唯一稳定可用场景，但容错不在前端
Flash、Java、ActiveX 等插件接口已在 Chrome 88+、Firefox 85+、Edge 90+、Safari 14+ 中彻底移除。<object type="application/x-shockwave-flash"></object> 不会加载、不报错、不触发 onerror，只留白。
PDF 嵌入虽可用，但成败关键在服务端和部署层：
- 必须用 HTTP(S) 协议访问，
file://下多数浏览器拒绝加载 - Nginx/Apache 必须配置
application/pdfMIME 类型，否则返回text/plain或application/octet-stream就会 fallback 或下载 - 移动端（iOS Safari、微信 WebView）常忽略 fallback，直接调起系统应用或静默失败
- 想可靠控制加载行为？别依赖
onload或contentDocument—— 它们在 PDF 场景下基本不可用，contentDocument为null是常态
真正容易被忽略的点是：PDF fallback 是否在服务端 404、CORS 阻止、Content-Type 不匹配、加载超时等任意一种异常下都保持一致触发——这需要后端响应策略统一，而不是前端多写几层 <object></object> 嵌套。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
