type属性本身不触发校验，浏览器对错误值静默处理；其作用仅限于与data指向的URL及服务端Content-Type响应头协同生效，且需严格匹配（尤其启用typemustmatch时）。
type 属性本身不触发任何校验，浏览器不会报错
写错 type 值（比如 type="pdf" 或 type="application/pdf " 多了个空格）时，浏览器完全静默——既不报错，也不警告，DOM 中该 <object> 节点照常渲染，只是后续 fallback 行为可能失效。这是因为 type 只参与 MIME 协商，不决定是否发起请求，真正起作用的是服务端返回的 Content-Type 响应头。
验证 type 是否生效，必须配合 data 和服务端响应头
单独看 type 没意义，它只在以下组合中起作用：
-
data指向一个真实可访问的 URL（不能是file://、不能 404、不能跨域无 CORS） - 服务端对该 URL 的响应头中包含
Content-Type，且值与type匹配（或浏览器内置处理器能识别） - 加了
typemustmatch属性时，Content-Type必须严格等于type值，否则直接跳 fallback
例如：<object data="report.pdf" type="application/pdf" typemustmatch> —— 若 Nginx 未配置 application/pdf MIME 类型，返回 Content-Type: text/plain，则空白且 fallback 显示；去掉 typemustmatch，Chrome 可能仍尝试解析为 PDF（但不可靠）。
用开发者工具快速判断 type 是否被采纳
打开浏览器 Network 面板，找到 object 的 data 请求，检查响应头：
立即学习“前端免费学习笔记（深入）”；
- 确认
Content-Type字段存在且值正确（如application/pdf） - 对比 HTML 中
type值是否完全一致（区分大小写、空格、分号） - 若用了
typemustmatch，但响应头是application/x-pdf，即使语义等价，也会拒绝渲染 - 查看 Preview / Response 标签页：如果是 PDF 却显示乱码或下载弹窗，大概率是
Content-Type错了
常见 type 写法陷阱与对应 MIME 类型
这些值看似合理，实则无效：
-
type="pdf"→ 缺少application/前缀，浏览器无法识别 -
type="application/pdf; charset=utf-8"→charset对 PDF 无意义，且多数服务端不返回该参数，导致typemustmatch失败 -
type="image/svg"→ 正确应为image/svg+xml，漏掉+xml会使部分旧浏览器降级 -
type="text/html"用于嵌套 HTML？不行。现代浏览器禁止在<object>中加载同源 HTML（会触发 CORS 策略或直接 block），fallback 才是唯一可靠路径
真正稳定可用的 type 极少：PDF 必须用 application/pdf，SVG 用 image/svg+xml，纯文本用 text/plain（但 fallback 更可控）。其他类型基本只剩历史兼容价值。
