type属性不触发请求，仅参与mime协商：data成功加载后，type与响应头content-type匹配才渲染，否则fallback；data无效时type完全不生效。
type 属性不是“告诉浏览器加载什么”，而是参与 MIME 类型协商——它只在资源已成功加载后，才和响应头里的 Content-Type 一起决定是否渲染。写错、留空、甚至不写，都不阻止请求发起；但匹配失败，就大概率触发 fallback。
type 值必须与服务端响应头一致，不能靠猜
浏览器最终是否渲染，取决于服务端返回的 Content-Type 响应头，而非你写的 type。常见误配：
-
type="application/pdf"写对了，但服务器返回Content-Type: text/plain→ Chrome 直接下载，不内嵌 -
type="image/svg+xml"没问题，但 Nginx 配置漏加 SVG MIME 类型 → 返回application/octet-stream→ fallback 显示 -
type="pdf"或type="image/jpg"是无效值，现代浏览器直接忽略，降级为无类型协商
验证方式：打开 DevTools → Network → 找到对应资源 → 查看 Response Headers 中的 Content-Type 字段。
PDF 场景下 type 是硬性门槛，且大小写敏感
Chrome/Firefox/Safari 对 PDF 的内建支持，仅响应 type="application/pdf"（全小写，带 application/ 前缀）。其他写法均失效：
-
type="pdf"→ 不识别，fallback 激活 -
type="application/PDF"→ Safari 16+ 可能拒绝解析（大小写敏感） -
type=""或省略 → 依赖响应头，但若服务端返回application/octet-stream，多数浏览器放弃内嵌
注意：typemustmatch 属性会强制校验 type 与响应头完全一致，调试阶段建议先不加，避免过度拦截。
SVG 场景下 type 有冗余性，但不可省略
SVG 文件即使不写 type，部分浏览器也能靠文件扩展名或响应头推断；但显式声明 type="image/svg+xml" 能提升 fallback 触发可靠性：
- 不写
type+ 服务端返回text/plain→ 浏览器可能尝试解析，也可能静默失败（不触发 fallback） - 写了
type="image/svg+xml"+ 同样响应头 → 明确不匹配 → 稳定 fallback 到内部<img> - 写了
type="image/png"却指向 SVG 文件 → 必然 fallback，属于人为错误
特别注意：iOS Safari 对 type 声明更敏感，未声明或声明错误时，<object></object> 可能渲染为空白却无 fallback，务必实测。
data 为空或非法时，type 完全无效
type 不是独立生效的属性。只要 data 没有指向一个可解析的 URL，整个 <object></object> 就处于“未激活”状态：
-
data=""、data=" "、data="javascript:void(0)"→ 浏览器不发请求，也不渲染 fallback -
data="report.pdf?name=张三"→ 中文未 URL 编码 → 部分浏览器截断请求，控制台无报错，fallback 不出现 -
data="file://local/doc.pdf"→ 现代浏览器静默阻止，DOM 中节点存在但无网络行为
也就是说，type 的作用前提是 data 已正确触发一次 HTTP 请求并收到响应。没这一步，type 就只是个字符串。
真正容易被忽略的是：fallback 不是“加载失败兜底”，而是“加载成功但无法处理”的最后防线。很多问题表面是 type 写错了，根因其实是服务端配置、路径拼写、CORS 或本地协议限制——得一层层排除，不能只盯着 HTML 标签改。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
