object标签当前仅PDF嵌入真正可用，需data与type严格匹配、服务端返回Content-Type: application/pdf，并加typemustmatch校验；HTML和SVG嵌入均存在严重兼容性与交互限制。
object 标签现在只在极少数场景下真正可用——PDF 嵌入是当前最稳定、可落地的用法；嵌入 HTML 文件虽语法上允许，但浏览器支持断裂、行为不一致，实际项目中基本不可靠。
PDF 嵌入：data 和 type 必须严格配对
失败往往不是标签写错了，而是服务端或路径配置没对齐：
-
data必须指向可访问的 PDF 文件（如"./docs/manual.pdf"），且服务器返回的响应头必须为Content-Type: application/pdf；否则 Chrome/Firefox 会直接下载或显示空白 -
type必须写成"application/pdf"，写成"pdf"、"text/pdf"或留空，都会跳过渲染直接 fallback - 加
typemustmatch属性可强制校验响应头与type一致，避免“返回 HTML 却当 PDF 渲染”的错位 - 本地开发时用
file://协议，Firefox 可能忽略type、只按后缀判断；务必用http://localhost启服务预览
HTML 文件嵌入：浏览器支持残缺，慎用
虽然规范允许 object data="header.html" type="text/html"，但现实很骨感：
- Safari 16+ 完全不支持
object加载 HTML；Chrome 部分版本会加载但无交互上下文；Firefox 在file://下直接拒绝 - 即使加载成功，嵌入的 HTML 是隔离子文档，主页面 JS 无法直接操作其 DOM，
contentDocument仅同源可用，且多数情况下为null - 不设
width和height会导致区域塌陷成几像素高，视觉上“消失”，这不是 bug，是默认渲染行为 - fallback 内容只有在明确加载失败（404/CORS/响应头不匹配）时才触发，不是“没显示就降级”——这点常被误判
SVG 嵌入：缩放和脚本交互有硬限制
用 object 加载 SVG 看似可行，但实际埋了几个深坑：
立即学习“前端免费学习笔记（深入）”；
-
width/height会覆盖 SVG 自身的viewBox缩放逻辑，设为"100%"或不设更利于响应式，但父容器必须有明确宽度 - SVG 内部的 JS 事件（如
<g onclick="...">）无法被主页面监听，contentDocument不可用，交互链断裂 - 若 SVG 引用了外部资源（如
<use href="icon.svg#x">），跨域请求必然失败；此时用<img src="icon.png">fallback 更实际 - 不要写
type="image/svg+xml"却让data指向 PNG 文件——这是人为制造不匹配，必然 fallback
真正容易被忽略的点是：你写的 object 标签本身没问题，但服务端响应头、本地协议限制、浏览器版本差异、甚至 fallback 内容是否为合法 HTML 子节点（纯文本不算），任何一个环节出错都会导致“白屏”或“静默 fallback”。它不是“写了就能用”的通用嵌入方案，而是一个需要逐层验证的脆弱链路。
