object标签仅对PDF和同源SVG可靠，PDF需type="application/pdf"且服务端Content-Type匹配；HTML嵌入不稳定，SVG需注意尺寸与跨域；务必用curl -I验证响应头。
object 标签不是“通用在线文件加载器”，它只在特定类型、严格匹配条件下才可靠工作——最稳的是 PDF，其次是同源 SVG；其他格式（如 DOCX、XLSX、HTML）要么 fallback 频繁，要么行为不一致，别硬套。
PDF 文件必须显式声明 type 且服务端响应头匹配
浏览器不会靠文件扩展名或 URL 后缀判断内容类型，type="application/pdf" 是硬性前提。但光写这个不够：
- 服务端返回的
Content-Type响应头也得是application/pdf，否则 Chrome/Firefox 会直接下载或白屏 - 加
typemustmatch属性可强制校验——比如后端误返回 HTML 错误页，加了它就不会静默渲染成乱码 - 本地开发用
file://协议时，Firefox 会忽略type、只认后缀；务必用http://localhost启服务预览 - URL 中含空格或中文？必须
encodeURIComponent()编码，否则触发net::ERR_INVALID_URL
嵌入 HTML 文件需设 type="text/html" 且接受兼容性限制
虽然规范允许，但实际中：object 加载 HTML 的行为远不如 iframe 稳定：
- 必须写
type="text/html"，不写或写错（如text/plain）会导致 fallback 或空白 - 内部 HTML 的脚本默认执行，但无法通过主页面 JS 访问其
window或document（跨域隔离） - Safari 对
object加载 HTML 支持弱，iOS 微信内置浏览器可能直接跳转下载 - 如果只是想复用页脚/导航等静态片段，
fetch+innerHTML更可控；object仅适合“需要原生 fallback 文本”的轻量场景
SVG 嵌入要注意 DOM 隔离和尺寸陷阱
object 是目前唯一能保持 SVG 内部交互（如 <g onclick>）且提供 fallback 的原生方式，但代价明显：
立即学习“前端免费学习笔记（深入）”；
-
width/height会覆盖 SVG 自身的viewBox缩放逻辑；设为100%或不设更安全，但父容器必须有明确宽度 - SVG 里用
<use href="icon.svg#x">引用外部资源？跨域即失败，fallback 到<img src="icon.png">更实际 -
contentDocument只在同源时可用，且 PDF 场景下该属性为null——别指望 JS 动态改 SVG 内容 - 不要写
type="image/svg+xml"却让data指向 PNG，这是人为制造不匹配，必然 fallback
真正麻烦的从来不是怎么写标签，而是验证：Mac Safari 显示正常，Windows Edge 白屏，iOS 微信直接下载——这些差异往往来自服务端响应头、协议限制或浏览器对 typemustmatch 的实现偏差。别跳过 curl -I 查响应头这一步。
