type属性仅作提示，不决定加载或渲染；实际MIME类型由服务器Content-Type响应头决定，type仅参与协商、影响fallback触发概率及旧浏览器插件选择。
type 属性不是“填对就能用”，它只在特定条件下起作用，多数时候你填了也白填——浏览器根本不看它是否匹配，真正决定能否渲染的是服务端返回的 Content-Type 响应头。
type 属性到底影响什么
它不触发请求，不决定加载与否，也不校验文件内容。它的实际作用非常有限：
- 仅参与 MIME 类型协商：浏览器拿到响应后，会比对
type值和响应头里的Content-Type，若一致且该类型有内置处理器（如 PDF、SVG），就尝试内嵌渲染 - 旧浏览器（IE）曾用它选择 ActiveX 插件，现代浏览器已完全弃用插件机制
- 配合
typemustmatch属性时，可强制要求二者必须一致才加载（但兼容性差，Chrome 仅部分支持，Safari 不支持） - 空
type或缺失时，fallback 触发门槛变高——比如服务器返回application/octet-stream，有type="application/pdf"更容易被识别为“可处理但失败”，从而显示 fallback
常见 type 值怎么写才不算错
写错值一般不会报错，但可能让 fallback 失效或误导调试。注意这些细节：
-
image/svg+xml✅ 不是image/svg❌（后者不是标准 MIME 类型） -
application/pdf✅ 不是application/x-pdf❌（后者非 IANA 注册类型） -
text/html✅ 用于嵌入网页，但需注意同源策略和 CORS；跨域时即使type正确，也可能因响应头缺失Access-Control-Allow-Origin而静默失败 -
audio/mpeg、video/mp4等虽合法，但实际渲染由<audio>/<video>更可靠，<object>对音视频支持不稳定，不推荐
data 和 type 不一致时会发生什么
这是最容易误判的点。举几个典型场景：
立即学习“前端免费学习笔记（深入）”；
-
data="report.pdf"+type="text/plain"：请求照发，PDF 文件也能下载，但浏览器不会尝试内嵌渲染（因类型声明与实际用途矛盾） -
data="chart.svg"+type="image/png"：如果服务端响应头是image/svg+xml，Chrome 仍能正常显示 SVG；但如果响应头是image/png（而文件其实是 SVG），就会乱码或空白 -
data="doc.pdf"+type="application/pdf"，但服务器返回Content-Type: text/html（比如 404 页面）：浏览器识别为“HTML 内容”，可能直接跳转或弹窗下载，fallback 不触发
真正该优先检查的不是 type，而是 data 和响应头
绝大多数 <object> 渲染失败问题，根源不在 type，而在：
-
data值是否为空、含非法字符（如未编码的中文）、路径错误（漏./或多写../） - 服务端是否返回了正确的
Content-Type（用 DevTools → Network → 查看响应头） - 跨域资源是否配置了
Access-Control-Allow-Origin - 用户是否禁用了内置 PDF 查看器（此时即使一切正确，也会退到 fallback）
type 属性最常被忽略的复杂点是：它看起来像“开关”，实则是“提示标签”——你填得再准，也拦不住服务端返回一个错的 Content-Type。
