前端图片加载失败与裂图原因全解析

一个通过 HTTPS 加载的页面，去请求**非 HTTPS（HTTP）**的资源。

User agents must rewrite insecure schemes to secure schemes before fetching the resource.

This does not affect the DOM or the URL reflected to script.

<!-- 页面本身是 https://example.com -->
<img src="http://img.example.com/a.png">

此时页面是安全的，但图片请求是不安全的，浏览器会认定为'混合内容'。

3.2 为什么要阻止混合内容？

因为 HTTP 请求容易被中间人攻击。攻击者可以篡改图片、注入恶意脚本、或监听请求，从而破坏整个 HTTPS 页面的安全性。

3.3 混合内容的两种类型

3.4 可升级内容（Upgradable Content）

从 Chrome 80+ / Edge 79+ / Firefox 83+ 起，浏览器对某些被动混合内容启用了'自动升级机制'。当页面是 HTTPS 时，如果 <img> 的地址是 HTTP，浏览器会尝试自动改为 HTTPS 重新加载。

3.4.1 举例说明：

<!-- 页面是 https://page.com -->
<img src="http://cdn.page.com/pic.png" />

浏览器会自动尝试请求：

https://cdn.page.com/pic.png 

如果资源服务器支持 HTTPS，就会成功显示。如果不支持或证书无效，加载失败（显示裂图）。

注意浏览器在 network 面板请求的是 https 请求，但是 DOM 中还是显示的 http 地址，浏览器可不会自动修改你的 DOM。

那么问题来了，为啥 DOM 没变但是渲染的是 https？

因为 请求完成后，浏览器渲染的是'响应的二进制内容'，不是 URL

图片 <img> 加载流程其实是：DOM 给出 URL 字符串（http）Resource Loader 把它升级成 https 并发送请求请求返回后产生一个 decoded image bitmap（解码好的位图）<img> 标签拿到的是'图片数据对象'（Image Bitmap / Image Document）把这个 bitmap 交给渲染引擎绘制在页面上

也就是说，渲染用的不是 URL，而是'图片数据'

3.4.2 浏览器不会把 改成 https

因为 URL 升级只是加载规则（fetching rule）的结果，不是文档结构 (DOM) 的改变。

浏览器的设计理念：

• DOM = 你的代码
• Loaders = 浏览器的行为

浏览器永远不会篡改你的 DOM 代码，只在加载阶段更换 URL。

3.5 哪些资源属于'可升级内容'

📘 官方文档参考：MDN: 混合内容（Mixed Content）

3.6 注意：不是'所有场景'都自动升级

• 升级依赖浏览器支持；
• 如果资源使用了 IP、非标准端口或证书无效，不会升级；
• 如果页面设置了 CSP：
• 则会强制所有 HTTP 请求都升级为 HTTPS
• 升级失败依然会导致裂图。

Content-Security-Policy: upgrade-insecure-requests 

3.7 为什么以前的说法是'不会自动改为 https'

因为在 Chrome 80 之前（2020 年以前），浏览器并不具备'自动升级'行为，只是警告或阻止。现在的混合内容机制是新一代浏览器安全策略的演进结果。

3.8 HTTP 页面加载 HTTPS 图片会怎样？

不会触发混合内容，HTTP 页面加载 HTTPS 图片完全合法，只是页面本身不安全。

四、其他容易忽略的裂图原因

4.1 跨域限制（Canvas 绘制）

若 <img> 跨域加载资源后再画到 <canvas> 上，未设置 crossorigin 会触发安全限制。

4.2 图片过大或加载超时

大图未能在超时时间内返回，可能表现为裂图。

4.3 服务端缓存头异常

过期或 ETag 不匹配，导致 CDN 无法正确命中图片。

五、排查与修复建议

六、总结

混合内容机制是现代浏览器为保证 HTTPS 安全性而做出的妥协与平衡。对于前端开发者而言，理解它的升级与阻止逻辑，是解决'裂图'的关键。