现代浏览器中object和embed标签已无法加载Flash、音视频等插件，仅PDF在严格满足路径、MIME类型及宽高条件时偶有残余支持；推荐用iframe嵌PDF、video/audio播媒体、iframe载第三方页面。
现代浏览器里直接用 <object> 或 <embed> 嵌 PDF、音视频、Flash，基本等于白写——不是“可能不显示”，而是“必然不执行插件加载逻辑”。NPAPI 插件支持已在 Chrome 88+、Firefox 85+、Edge 90+、Safari 14+ 中彻底移除，空白是浏览器主动跳过的结果，不是加载失败。
为什么 <object> 的 fallback 经常不渲染
fallback 不是“只要写进去就一定显示”，它只在极少数明确失败场景下触发：
-
data指向 404 资源时，Firefox 通常会渲染内部 HTML；Chrome 却常留空框，把它当作“资源未就绪”继续等待 -
type="application/pdf"但服务端没返回对应 MIME 头（如Content-Type: application/pdf），Safari 直接拒绝加载，且不触发 fallback -
type="application/x-shockwave-flash"这类旧 MIME 类型仍被识别，只是“不可执行”，规范不认为这属于 fallback 触发条件 - IE11 兼容模式下若缺失
classid或codebase，报“未注册对象”错误，且内部 HTML 也不执行
为什么 <embed> 在 Safari 和 Chrome 88+ 里总留白
<embed> 是自闭合标签，天生不支持内部 fallback 内容，失败时纯静默：
- 它只按文件扩展名或响应头
Content-Type决定是否加载，一旦不匹配（比如服务器返回text/plain而非application/pdf），就静默失败，无提示 - Safari 对本地 PDF 的
<embed src="doc.pdf">渲染完全禁用，即使路径正确也强制下载，而非内联预览 - Chrome 88+ 彻底忽略
type="application/x-shockwave-flash"，既不报错也不渲染，<embed src="xxx.swf">等价于一个空 DOM 节点 - 微信 WebView（X5 内核）对
src或type解析极不稳定，PDF 和 SVG 常被截断或静音
嵌 PDF / 音视频 / 第三方页面该用什么替代
不是“选一个标签”，而是按内容类型严格对应语义化现代方案：
立即学习“前端免费学习笔记（深入）”；
- Pdf 文件：
<iframe src="doc.pdf">—— Safari 和 Chrome 内置 PDF 渲染器支持 iframe 内联，可响应sandbox和loading="lazy"，且onerror可捕获失败并替换 DOM - 音视频：
<video>或<audio>—— 必须用原生标签，它们原生支持preload、controls、poster，无需插件，<source>可声明多格式回退 - 第三方页面（如地图、登录弹窗）：
<iframe>—— 它有沙箱隔离、CSP 控制能力，且现代浏览器对其加载策略（如懒加载、跨域通信）有完整支持
<object> 套 <embed> 还有效吗
无效。这种写法曾用于兼容 IE（认 <object>）和 Firefox/Chrome（降级到 <embed>），但现在所有主流浏览器都已放弃插件加载能力：
- Chrome 和 Edge 直接忽略整个
<object>块，哪怕里面写了<embed> - Safari 可能解析
<embed>，但因无插件支持而静默失败，不报错也不 fallback - 当
<object>包含<embed>且同时设置data和src时，不同浏览器取值优先级不一致：Firefox 读data，Chrome 读src，行为不可控 -
<param>在 Chromium 内核中已被静默降级，PDF 页面跳转等参数应拼在dataURL 后，如data="doc.pdf#page=3"，而非依赖<param name="page" value="3">
最容易被忽略的一点是：现代项目中，<object> 和 <embed> 不再是“兼容性选项”，而是“技术债标识”——只要还在用它们，就意味着你仍在为已不存在的插件机制做适配。真正的兼容，是用 <iframe> + JS 错误处理、<video> + <source> 回退、PDF.js 等可验证、可调试、可监控的现代路径。
