fallback内容必须写在object标签内部且为合法HTML流内容，浏览器仅在data返回404、type未注册或typemustmatch校验失败时渲染；script、iframe等可执行标签会被忽略甚至阻塞渲染。
fallback内容必须写在
浏览器只会在
- ✅ 正确：
<object data="doc.pdf" type="application/pdf"><p>PDF加载失败，请<a href="doc.pdf">点击下载</a></p></object> - ❌ 错误：
<object data="doc.pdf"><script>location.href='fallback.html'</script></object>—— 脚本不会执行，还可能阻塞解析 - ⚠️ 注意：
<param>标签不参与fallback，它只对成功加载的插件生效；降级时你读不到原始data值，得提前用JS提取存变量
为什么写了fallback却没显示？常见触发条件不匹配
很多人以为只要data路径不对就一定走fallback，其实不是。Chrome只在HTTP状态码为404或MIME类型与type严重不匹配时才触发；Firefox更激进，插件未启用、CSP拦截、甚至type="application/x-shockwave-flash"这种已废弃类型，都可能直接展示fallback——哪怕服务器返回了200和HTML内容。
- PDF场景下，若服务端返回
Content-Type: text/html但type="application/pdf"，加typemustmatch才能强制fallback -
type="pdf"或留空，浏览器根本不会尝试PDF渲染，直接走fallback，这不是错误而是预期行为 - 本地开发用
file://协议时，Firefox常忽略type，只看文件后缀，此时fallback几乎不触发
想动态控制fallback？别写死，用onerror + DOM操作
onerror事件在现代浏览器中对<object>支持不稳定：Flash/Java类插件失败时不触发；PDF加载失败时Chrome可能触发，Firefox则不一定。所以依赖它做兜底不可靠，但真需要JS逻辑（比如上报错误、切换iframe），必须用事件+动态注入，而不是把逻辑硬塞进标签体。
- 先提取配置：
const obj = document.querySelector('object'); const src = obj.getAttribute('data'); - 再绑定：
obj.addEventListener('error', () => { obj.innerHTML = '<p>加载异常，正在重试...</p>'; }); - 避免
document.write()——它会清空整个页面，仅限极老环境
真正该考虑的是：现在还该用object吗？
PDF用<iframe src="xxx.pdf">更稳，音视频必须用<video>或<audio>，SVG交互必须内联。只有两种情况值得保留<object>：一是需无JS环境下的多层HTML fallback（比如政府静态页面），二是服务端能严格控制响应头且需typemustmatch强校验的PDF场景。其他所有用途，包括Flash、Java Applet、SWF图表，均已失效，fallback只是幻觉。
立即学习“前端免费学习笔记（深入）”；
最容易被忽略的一点：微信内置WebView对object的data路径解析极不稳定，中文路径、query参数未编码、相对路径层级过深，都可能导致白屏而非fallback——这时连onerror都不触发，唯一解法是提前转成绝对URL并encodeURIComponent。
