object标签加载由data属性触发，不参与html预加载；data为空或非法时静默白屏，不触发fallback；仅当请求失败或content-type不匹配时才启用fallback；嵌套object串行加载且无超时机制；移动端safari对pdf渲染不可控，推荐用iframe替代。
object标签的加载时机由data属性触发，不参与HTML预加载队列
浏览器解析到 <object></object> 标签时，不会像 <link rel="preload"> 或 <img> 那样提前发起请求；它只在 DOM 构建完成、遇到该标签并确认 data 属性存在后，才开始加载。这意味着：如果 data 指向一个大 PDF，而它又写在 开头，就会立刻抢占带宽，挤掉后续关键资源（比如首屏 CSS 或 JS）。
常见错误现象包括：把 <object data="report.pdf"></object> 放在 里（无效，data 在 中被忽略），或放在首屏 <div> 顶部却没加 <code>loading="eager"（现代浏览器对 <object></object> 不支持 lazy loading，但位置靠前仍会抢发请求）。
-
data必须是有效 URL，空值、javascript:void(0)或拼错路径（如多一个斜杠）会导致静默白屏，不触发 fallback - 服务器返回非 200（如 404/500）或 Content-Type 与
type不匹配时，才会进入 fallback 流程 - 不要对
data指向的资源做<link rel="preload">—— 浏览器无法预判其 MIME 类型，preload 会失效且可能报错
嵌套 object 的加载是串行的，不是并行 fallback
写成 <object data="chart.svg"><object data="chart.png"><p>图表不可用</p></object></object> 看似“多层保险”，实际加载逻辑是：先请求 SVG，失败后再请求 PNG，再失败才显示文字。中间没有并发，也没有超时控制——若 SVG 请求卡在 DNS 或 TLS 握手，PNG 就一直等不到机会。
这种结构只适合已知各层响应极快（如本地静态文件）、且网络异常类型明确（如仅防 404）的场景。线上弱网环境更推荐单层 + 明确降级策略，比如用 JS 监听 load 和 error 事件后主动切换。
- 每层
<object></object>都独立校验data和type，写错任意一层的type（如"image/svg"应为"image/svg+xml"）都会跳过该层 - 嵌套层级越深，DOM 查询和事件监听越复杂，容易漏掉内层
load事件绑定 - Firefox 在
file://协议下可能跳过外层type校验，直接尝试加载，导致 fallback 不触发
object 的 load 事件不等于资源“可用”，contentDocument 访问有同源限制
load 事件只表示嵌入文档加载完成（类似 iframe），不代表你能立即读取其中内容。如果 data 指向跨域 PDF 或 HTML 片段，objectEl.contentDocument 会是 null，JS 无法提取表格或文本。
想从 <object type="text/html"></object> 里取表格？必须满足：同源、服务端返回 Content-Type: text/html、且 load 后用 document.importNode() 搬运节点。直接 appendChild(objectEl.contentDocument.body) 会报错。
- PDF 嵌入永远拿不到
contentDocument，内置查看器是沙箱化 UI，不暴露 DOM - SVG 嵌入可访问
contentDocument，但需等load后再查，DOMContentLoaded对它无效 - 不要用
setTimeout等 contentDocument 出现——它要么立即有，要么永远为 null
移动端 Safari 对 object 的 PDF 渲染行为最不稳定
iOS 17+ 的 Safari 默认用系统 PDF 查看器渲染 <object type="application/pdf"></object>，但该查看器不继承页面 CSS、不响应 width/height 设置、滚动行为也和页面不一致。更麻烦的是：它有时会拦截 load 事件，导致你监听不到加载完成；有时又在 PDF 还没完全解码时就触发 load，contentDocument 依然为空。
这不是 bug，而是设计使然——Safari 把 PDF 当作“外部应用”而非页面一部分来处理。所以依赖 object 实现 PDF 首屏可交互的方案，在 iOS 上基本不可靠。
- 避免给 PDF
<object></object>设width="100%"，Safari 可能渲染成固定宽度并横向溢出 - 不要指望通过 JS 控制 PDF 缩放或跳页，iOS 查看器不提供对应 API
- 真要可控 PDF 渲染，用
<iframe src="report.pdf"></iframe>更稳定（虽也不支持脚本交互，但尺寸和事件行为更可预期）
真正难处理的不是怎么写 <object></object>，而是判断什么时候不该用它——比如动态表格、需要 JS 交互的图表、或要求首屏秒开的 PDF 预览，都该换方案。它的价值只在「纯静态、强降级、零 JS 依赖」的弱网兜底场景里成立。
