的 type 属性仅作提示，不控制解析；实际 mime 类型由 http content-type 响应头或内联方式（如 、data url）决定，本地 file:// 协议下因无响应头而默认为 text/plain。
MIME 类型不是通过 _OBJECT 标签的 TYPE 属性“设置”的——这个属性只用于声明（hint），浏览器不强制执行，也不影响实际解析逻辑。
为什么 type 属性在 <object></object> 中几乎不起作用
HTML 的 <object></object> 元素的 type 属性是可选的，仅作为“建议类型”供浏览器参考。它不会覆盖 HTTP 响应头中的 Content-Type，也不会触发格式转换或 MIME 检查。如果服务端返回的响应头是 Content-Type: text/plain，哪怕你写 type="application/pdf"，浏览器仍按纯文本处理（通常显示为乱码或下载失败）。
常见错误现象：
- PDF 文件嵌入后空白，控制台报
Failed to load resource: net::ERR_INSECURE_RESPONSE或直接显示源码 - SVG 显示为 XML 文本，而非图形
-
type="image/svg+xml"但 SVG 里含<script></script>被静默禁用（因实际加载方式是 inline + MIME 决定执行权限）
真正起效的 MIME 类型控制点只有两个
浏览器最终如何解析一个资源，取决于且仅取决于：HTTP 响应头的 Content-Type，以及该资源是否被 inline 到 HTML 中（如 data URL 或 <svg></svg> 标签）。<object></object> 的 type 属性无法干预这两者。
- 对外部资源（
data="report.pdf"）：必须由 Web 服务器在响应时返回正确的Content-Type: application/pdf - 对内联 SVG：直接写
<svg>...</svg>，此时无 HTTP 请求，MIME 由 HTML 解析器根据标签推断（<svg></svg>→image/svg+xml） - 对 data URL：
data:application/pdf;base64,...中的application/pdf是 data URL 协议的一部分，会被识别，但部分浏览器（如 Safari）对 data URL 的type支持有限，仍可能 fallback 到text/plain
<object type="..."></object> 的唯一可靠用途
它只在“备用内容降级”和“插件协商”场景下有意义——且仅限旧浏览器（如 IE、Firefox 早期支持 NPAPI 插件时）。现代浏览器已移除插件支持，type 属性只剩语义提示和降级判断价值。
- 当资源加载失败或 MIME 不匹配时，浏览器会渲染
<object></object>内部的内容（如<p>请安装 PDF 阅读器</p>） - 你可以用 JavaScript 检测
object.type是否被识别（object.contentDocument === null通常表示加载失败或类型不支持） - 不要依赖它做类型校验：即使
type="application/json"，浏览器也根本不会尝试解析 JSON；<object></object>不支持 JSON 渲染
替代方案：什么时候该换标签
如果你发现反复纠结 <object type="..."></object> 却得不到预期行为，大概率是选错了元素。
- 显示图片？用
<img src="chart.svg" type="image/svg+xml">（注意：<img>的type属性仅用于<picture></picture>的<source></source>，本身不生效）→ 实际应直接用<img src="chart.svg">，靠服务端发对 MIME - 嵌入交互式 SVG？直接内联
<svg>...</svg>，避免<object></object>的沙箱限制（比如无法访问父文档 CSS、<script></script>默认不执行） - 需要 PDF 查看？优先用
<iframe src="doc.pdf"></iframe>（更稳定，多数浏览器内置 PDF 查看器），或调用pdf.js库
最常被忽略的一点：本地开发时用 file:// 协议打开 HTML，所有 <object></object> 加载的外部资源都会因缺失 HTTP 头而被当成 text/plain —— 这不是 type 属性的问题，是协议限制。必须走 HTTP 服务（如 python3 -m http.server）才能让 MIME 生效。
