type属性是资源类型声明而非可选提示，不匹配时浏览器直接放弃加载主资源并渲染后备内容；关键在于写好后备路径，如<img>或<p>，而非依赖onerror或type错误提示。
type属性不匹配时
type不是可选提示，而是资源类型声明。浏览器拿到data地址后，会先检查响应头的Content-Type是否与type值一致；不一致就直接放弃加载——此时内部后备内容（如<img>或文本）才会渲染。这不是“提示”，而是降级机制本身。
真正起作用的是后备内容，不是type错误提示
你无法让浏览器在type不支持时“弹个提示框”，它只会静默跳过主资源，转而渲染<object>标签内的子内容。所以关键不是捕获type错误，而是写好后备路径：
- 把最简可用内容放在
<object>标签内部，比如<img src="fallback.png">或<p>图表不可用</p> - 避免只放纯文本——某些旧浏览器（如 IE）对空后备内容处理异常，至少加一个
<div></div>兜底 - 不要依赖
onerror事件：HTML 规范没给<object>定义该事件，Chrome/Firefox 均不触发
typemustmatch=true能帮你提前暴露问题
加typemustmatch属性后，浏览器会严格比对type和实际资源类型。如果服务器返回text/plain但你写了type="image/svg+xml"，资源连请求都不会发出去——这反而利于调试：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 打开 DevTools 的 Network 面板，看对应资源是否发出请求
- 若没发请求，说明
typemustmatch拦住了；若发了但状态码是 404 或 500，那是服务端问题 - 临时去掉
typemustmatch，确认后备内容能否正常显示，再逐步排查type和响应头是否一致
移动端或无插件环境里，type基本形同虚设
现代浏览器已移除 NPAPI 插件支持，type="application/x-java-applet"或type="application/x-shockwave-flash"这类值毫无意义。即使type写对了，资源也加载不了——此时唯一可靠的是后备内容是否合理：
立即学习“前端免费学习笔记（深入）”；
- SVG 图表？后备用 PNG + 简短文字说明，别只写“加载失败”
- PDF 嵌入？后备提供下载链接：
<a href="doc.pdf">下载PDF版本</a> - 避免在后备内容里再嵌套
<object>——降级链过深会导致 Safari 渲染异常
后备内容不是补丁，它是<object>存在的理由。写得越实在，用户在各种环境下看到的东西就越确定。
