type属性仅在浏览器支持对应MIME类型时生效，优先级低于HTTP响应头Content-Type；无效type值触发fallback显示，现代开发中已基本被iframe、img等更可靠方案替代。
type 属性只在特定 MIME 类型下才生效
type 属性不是“万能类型开关”，它只在浏览器能识别且支持对应插件/内置处理器时起作用。比如设为 type="application/pdf"，Chrome 会调用内置 PDF 查看器；但设为 type="application/x-unknown"，多数现代浏览器直接忽略该值，退回到 data 的实际响应头 MIME 类型。
常见有效组合包括：
-
type="image/svg+xml"：加载 SVG 文件（需注意跨域和脚本执行限制） -
type="application/x-shockwave-flash"：已废弃，现代浏览器完全不支持 -
type="text/html"：可嵌入 HTML 片段，但受同源策略限制，且部分浏览器会阻止脚本执行 -
type="application/pdf"：依赖浏览器原生支持，Safari 在某些版本中可能弹下载而非内嵌
type 和 data 属性冲突时以 data 为准
浏览器优先信任 HTTP 响应头中的 Content-Type，type 属性仅作提示或 fallback。如果服务器返回的响应头是 Content-Type: image/png，但你在 <object> 上写了 type="application/json"，浏览器仍按 PNG 渲染（或报错），不会尝试解析为 JSON。
调试建议：
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的 Network 面板确认实际返回的
Content-Type - 避免仅靠
type“欺骗”浏览器行为，尤其在处理二进制资源时 - 若需强制类型解释（如本地
file://协议下无响应头），type才真正起作用，但兼容性差
type 属性对 fallback 内容的影响
<object> 的子内容（即 fallback 区域）是否显示，取决于 type 是否被识别 + 资源是否加载成功。如果 type 值无效（如拼错 MIME 类型）或对应处理器不可用，浏览器会跳过渲染并显示 fallback —— 但这个过程不触发 JS 错误，也无明确事件通知。
实操注意点：
- fallback 不是“备用 HTML”，而是“加载失败时的降级展示”，别在里面放关键交互逻辑
-
type值写错（如type="image/jpg"，正确应为image/jpeg）可能导致 Safari 完全不尝试加载 - 想监听加载状态？得靠
onload/onerror，但它们触发不稳定，尤其对 PDF 等内置类型
现代开发中 type 属性的实际价值很低
除极少数场景（如企业内网遗留系统要求指定 type="application/x-java-applet"），type 已基本被边缘化。主流替代方案更可靠：
- 嵌入 PDF：用
<iframe src="doc.pdf">，兼容性更好，事件可控 - 显示 SVG：直接内联
<svg>或用<img src="icon.svg"> - 动态内容：用
fetch()+DOMParser或框架组件封装，而非依赖<object>的黑盒行为
真正容易被忽略的是：即使你写了 type，浏览器也可能根本不读它 —— 尤其当资源通过 CORS 加载、或响应头已明确声明类型时。别把它当成类型断言工具。
