我要评论在前端开发过程中，我们几乎都遇到过这种情况：
页面中某张图片加载不出来，显示成一个小小的“裂图”图标。
这看似简单的问题，实际上可能由多种原因造成，尤其是在 https 环境下，混合内容机制（mixed content） 是最常见、也最容易被误解的根源之一。
本文将带你系统梳理裂图的各种原因、排查思路，并重点讲清楚混合内容的原理与浏览器行为。
一、什么是“裂图”？
“裂图”（broken image）是指浏览器尝试加载 <img> 标签的图片资源失败时的表现形式。
常见表现：
图片区域显示为灰底、叉号、占位符；
控制台出现
failed to load resource或mixed content警告；network 面板中图片请求状态码为 404 / 403 / blocked。
二、常见的裂图原因汇总
2.1 图片资源不存在
最基础的情况。可能是：
路径错误（相对/绝对路径混乱）；
资源被删除或未上传；
oss/cdn 缓存未刷新；
拼接 url 时丢失了参数（如签名 url 过期）。
排查建议：
打开 network 面板；
直接在浏览器地址栏访问图片 url；
看返回码是否为 404 或 403。
2.2 图片服务器防盗链（referer 校验）
很多图片或 cdn 都会校验 referer，限制图片只能在指定域名下访问。
如果请求来源不在白名单内，服务器会拒绝访问（403）。
典型症状：
network 状态码 403；
响应头中带有自定义防盗链提示。
解决办法：
通过后端代理请求；
或联系服务端将当前域加入 referer 白名单。
2.3 响应头设置错误（content-type/content-disposition）
如果返回头不是图片类型（例如
text/html），浏览器可能无法渲染；如果设置了
content-disposition: attachment，浏览器会触发下载行为，但现代浏览器对图片通常会放行显示。
2.4 权限与签名失效
某些云存储（如 oss / cos / s3）要求签名 url 才能访问。
签名过期后图片加载失败
2.5 csp 限制（content-security-policy）
如果页面设置了严格的 csp 策略，例如：
content-security-policy: img-src https://static.example.com
那么任何不在允许列表内的图片都会被阻止。
三、混合内容机制（mixed content）
这是前端 https 场景下导致“裂图”的核心原因之一。
这种情况一般控制台会报错：net::err_cert_common_name_invalid
3.1 混合内容是什么？
一个通过 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 混合内容的两种类型
| 类型 | 说明 | 浏览器行为 |
|---|---|---|
| 主动混合内容（active mixed content） | 能影响页面逻辑的内容，例如 <script>、<iframe>、xhr、css、websocket | 🚫 直接阻止 |
| 被动混合内容（passive mixed content） | 不影响逻辑的内容，例如图片、音视频、css 背景图 | ⚙️ 可能被升级或阻止 |
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 浏览器不会把< img src=""> 改成 https
因为 url 升级只是加载规则（fetching rule）的结果，不是文档结构(dom) 的改变。
浏览器的设计理念：
dom = 你的代码
loaders = 浏览器的行为
浏览器永远不会篡改你的 dom 代码，只在加载阶段更换 url。
3.5 哪些资源属于“可升级内容”
| 元素类型 | 是否会自动升级 |
|---|---|
<img> | ✅ 是 |
<audio> / <video> / <source> | ✅ 是 |
css 图片（background-image, border-image） | ✅ 是 |
<script> / <iframe> / xhr | ❌ 否，直接阻止 |
📘 官方文档参考：
mdn: 混合内容（mixed content）
3.6 注意：不是“所有场景”都自动升级
升级依赖浏览器支持；
如果资源使用了 ip、非标准端口或证书无效，不会升级；
如果页面设置了 csp：
content-security-policy: upgrade-insecure-requests
则会强制所有 http 请求都升级为 https
升级失败依然会导致裂图。
3.7 为什么以前的说法是“不会自动改为 https”
因为在 chrome 80 之前（2020 年以前），浏览器并不具备“自动升级”行为，只是警告或阻止。
现在的混合内容机制是新一代浏览器安全策略的演进结果。
3.8 http 页面加载 https 图片会怎样？
不会触发混合内容，http 页面加载 https 图片完全合法，只是页面本身不安全。
四、其他容易忽略的裂图原因
4.1 跨域限制（canvas 绘制）
若 <img> 跨域加载资源后再画到 <canvas> 上，未设置 crossorigin 会触发安全限制。
4.2图片过大或加载超时
大图未能在超时时间内返回，可能表现为裂图。
4.3服务端缓存头异常
过期或 etag 不匹配，导致 cdn 无法正确命中图片。
五、排查与修复建议
| 步骤 | 操作 | 检查内容 |
|---|---|---|
| 1 | network 面板 | 查看状态码 / 请求协议（http or https） |
| 2 | console 控制台 | 搜索 mixed content 或 failed to load resource |
| 3 | 直接访问 url | 检查是否可用、证书是否有效 |
| 4 | 检查 csp | 是否限制了 img-src 来源 |
| 5 | 检查响应头 | content-type、referer、防盗链策略等 |
六、总结
混合内容机制是现代浏览器为保证 https 安全性而做出的妥协与平衡。
对于前端开发者而言，理解它的升级与阻止逻辑，是解决“裂图”的关键。
| 类别 | 原因 | 浏览器行为 | 解决方案 |
|---|---|---|---|
| 资源不存在 | 404 | 裂图 | 修正路径 |
| 防盗链 | 403 | 裂图 | 调整 referer 或代理 |
| http → https 混合内容 | 被动混合内容 | 自动升级或阻止 | 改为 https |
| csp 限制 | 阻止加载 | 裂图 | 修改策略 |
| content-type 错误 | 无法解析 | 裂图 | 服务端修正 |
| 签名 url 失效 | 403 | 裂图 | 重新生成签名 |
到此这篇关于前端图片加载失败、 img出现裂图的原因超详细解析的文章就介绍到这了,更多相关前端图片加载失败原因内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论