如何通过HTML实现多格式图片降级-html教程-PHP中文网

是唯一原生多格式降级方案，因在Safari≤13.1、IE等旧浏览器中静默留白；必须严格写标准MIME类型（如image/webp），且与服务器Content-Type完全匹配，顺序应为avif→webp→jpg，末尾为强制兜底，src须指向静态可直访的JPG/PNG文件并含alt。

如何通过html实现多格式图片降级

是唯一能原生实现多格式降级的 HTML 方案，其他写法（比如只用）在 Safari ≤13.1、IE、旧 Android WebView 中会静默留白——不是加载慢，是根本没发请求。

为什么必须严格写 MIME 类型

浏览器只做字符串精确匹配：type="image/webp" ✅ 可识别；type="webp"、type="image/WebP"、type="image/jpg" ❌ 全部跳过，不报错也不警告。Safari 尤其敏感，拼错一个字母就直接忽略整条。

服务器响应头中的 Content-Type 必须和 type 值完全一致，否则 Chrome 可能侥幸加载，但 Safari 一定跳过
用 curl -I https://yoursite.com/photo.webp 检查返回头，确认是 Content-Type: image/webp
type="image/jpeg" 是标准写法，不是 image/jpg（后者不被规范承认）

的结构顺序不能错

浏览器从上到下线性扫描，遇到第一个 type 被支持 *且* 对应资源 HTTP 状态为 2xx *且* 能解码，就立即加载并停止后续检查。顺序错了，现代格式可能永远不生效。

推荐顺序： → →
AVIF 放最前：Chrome/Firefox/Edge 新版本已稳定支持；Safari 16.4+ 开始支持，但 iOS 16.4 以下需靠 WebP 接力
WebP 放中间：覆盖 iOS 14+、Android 4.0+、所有主流桌面浏览器
必须存在、必须在最后、src 必须指向静态可直访的 JPG/PNG 地址（不能带查询参数，如 ?format=webp）

为什么的 `src` 不能空、不能错、不能是 WebP

IE11 和旧版微信 WebView 完全不解析，它们直接忽略整个标签块，只渲染内部的。这个不是“备选”，而是这些环境里唯一的显示路径。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

src 必须真实可访问：在浏览器地址栏粘贴该 URL 应能直接显示图片
禁止写 src=""、src="missing.jpg"（文件实际不存在）、或相对路径错误（如 HTML 在子目录却写 src="img/logo.jpg"）
不要把当兜底——它在旧浏览器中照样留白
alt 属性不可省略，否则无障碍失败、SEO 折损，部分屏幕阅读器会跳过该元素

当加载失败时，不会自动接管

这是最常被忽略的坑：因 404、超时、格式损坏而失败时，浏览器不会“退到 ”，它只在“没有一条匹配成功”时才用。也就是说，media 条件满足但 srcset 地址无效，页面就留白。

轻量补救：给加内联 onerror，例如 onerror="this.src='/img/placeholder.svg'; this.onerror=null;"
this.onerror=null 必须写，否则 fallback 图再失败会无限循环
如果连 placeholder 都不可信，可用 base64 内联：data:image/svg+xml;base64,PHN2Zy...
本身不触发 error 事件，监听不到它的失败；如需强保障，得用 JS + fetch() 预检或 Service Worker 拦截