type属性仅是浏览器判断渲染处理器的辅助线索，不触发加载；真正决定资源处理方式的是服务端content-type响应头，type值仅作提示，二者不一致时以响应头为准。
type 属性本身不触发加载，也不决定资源能否显示——它只是浏览器判断“该用哪个内置处理器来尝试渲染”的辅助线索。填错、留空、甚至乱写，只要服务端响应头 Content-Type 正确，大多数现代浏览器照样能正常显示 PDF、SVG 或 HTML 片段。
type 属性只在 MIME 协商阶段起作用
浏览器拿到 data URL 后会发起请求，等响应返回时，才结合两个信息做类型判定：一是响应头里的 Content-Type，二是你写的 type 值。前者是权威，后者是提示。
- 如果两者一致（比如
type="application/pdf"且响应头也是application/pdf），浏览器大概率启用内置 PDF 查看器 - 如果
type写错（如写成application/x-pdf），但响应头正确，Chrome / Firefox 仍会渲染 PDF - 如果响应头是
text/plain，哪怕type="application/pdf"写得再准，浏览器也会下载或拒收 - 某些旧版 IE 会严格依赖
type调用 ActiveX 插件，但该行为已无现实意义
常见 type 值与对应内容的实际匹配效果
不是所有标准 MIME 类型都能触发预期渲染，关键看浏览器是否内置支持该类型处理器。
-
application/pdf：现代浏览器基本都支持内嵌，但需注意用户是否禁用了 PDF 查看器（此时 fallback 才生效） -
image/svg+xml：最稳妥的 SVG 嵌入方式，支持脚本交互和 CSS 样式继承；写成image/svg无效，IANA 不承认该类型 -
text/html：可用于嵌入同域 HTML 片段（如侧边栏），但跨域会受 CORS 限制；注意部分浏览器对text/html的object渲染有 sandbox 行为 -
application/x-shockwave-flash：仅历史兼容用途，当前所有主流浏览器已彻底移除 Flash 支持，设了也无用
typemustmatch 属性才是真正的“类型守门员”
如果你需要强制要求 type 和响应头完全一致才加载，必须显式添加 typemustmatch 布尔属性。否则它默认不生效。
- 没加
typemustmatch：浏览器忽略type值差异，以响应头为准 - 加了
typemustmatch但type与响应头不匹配：资源加载失败，直接走 fallback - 加了
typemustmatch且两者一致：按预期流程处理（渲染 / 下载 / 报错） - 示例：
<object data="report.pdf" type="application/pdf" typemustmatch><p>加载失败</p></object>
容易被忽略的细节：空 type 或缺失 type 的 fallback 触发概率更低
很多人以为不写 type 没关系，其实它会影响 fallback 的触发时机。
- 当服务端返回模糊类型（如
application/octet-stream或缺失Content-Type），有正确type值的object更可能被浏览器识别为“可尝试处理”，从而进入 fallback 流程 - 若
type缺失或为空，浏览器可能直接放弃协商，连 fallback 都不显示，表现为一片空白 - PDF 场景下尤其明显：Nginx 默认对
.pdf文件不设Content-Type，此时显式写type="application/pdf"是保障 fallback 可见的关键
真正决定成败的是服务端响应头，type 只是前端的一张“说明书”。写对它不能让坏响应变好，但写错或漏掉，可能让你连 fallback 都看不到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
