在前端開發(fā)過程中，我們幾乎都遇到過這種情況：

頁面中某張圖片加載不出來，顯示成一個(gè)小小的“裂圖”圖標(biāo)。

這看似簡單的問題，實(shí)際上可能由多種原因造成，尤其是在 HTTPS 環(huán)境下，混合內(nèi)容機(jī)制（Mixed Content） 是最常見、也最容易被誤解的根源之一。

本文將帶你系統(tǒng)梳理裂圖的各種原因、排查思路，并重點(diǎn)講清楚混合內(nèi)容的原理與瀏覽器行為。

一、什么是“裂圖”？

“裂圖”（broken image）是指瀏覽器嘗試加載 <img> 標(biāo)簽的圖片資源失敗時(shí)的表現(xiàn)形式。

常見表現(xiàn)：

• 圖片區(qū)域顯示為灰底、叉號、占位符；

• 控制臺出現(xiàn) Failed to load resource 或 Mixed Content 警告；

• Network 面板中圖片請求狀態(tài)碼為 404 / 403 / blocked。

二、常見的裂圖原因匯總

2.1 圖片資源不存在

最基礎(chǔ)的情況?？赡苁牵?/p>

• 路徑錯誤（相對/絕對路徑混亂）；

• 資源被刪除或未上傳；

• OSS/CDN 緩存未刷新；

• 拼接 URL 時(shí)丟失了參數(shù)（如簽名 URL 過期）。

排查建議：

• 打開 Network 面板；

• 直接在瀏覽器地址欄訪問圖片 URL；

• 看返回碼是否為 404 或 403。

2.2 圖片服務(wù)器防盜鏈（Referer 校驗(yàn)）

很多圖片或 CDN 都會校驗(yàn) Referer，限制圖片只能在指定域名下訪問。
如果請求來源不在白名單內(nèi)，服務(wù)器會拒絕訪問（403）。

典型癥狀：

• Network 狀態(tài)碼 403；

• 響應(yīng)頭中帶有自定義防盜鏈提示。

解決辦法：

• 通過后端代理請求；

• 或聯(lián)系服務(wù)端將當(dāng)前域加入 Referer 白名單。

2.3 響應(yīng)頭設(shè)置錯誤（Content-Type/Content-Disposition）

• 如果返回頭不是圖片類型（例如 text/html），瀏覽器可能無法渲染；

• 如果設(shè)置了 Content-Disposition: attachment，瀏覽器會觸發(fā)下載行為，但現(xiàn)代瀏覽器對圖片通常會放行顯示。

2.4 權(quán)限與簽名失效

某些云存儲（如 OSS / COS / S3）要求簽名 URL 才能訪問。
簽名過期后圖片加載失敗

2.5 CSP 限制（Content-Security-Policy）

如果頁面設(shè)置了嚴(yán)格的 CSP 策略，例如：

Content-Security-Policy: img-src https://static.example.com

那么任何不在允許列表內(nèi)的圖片都會被阻止。

三、混合內(nèi)容機(jī)制（Mixed Content）

這是前端 HTTPS 場景下導(dǎo)致“裂圖”的核心原因之一。

這種情況一般控制臺會報(bào)錯：net::ERR_CERT_COMMON_NAME_INVALID

3.1 混合內(nèi)容是什么？

一個(gè)通過 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">

此時(shí)頁面是安全的，但圖片請求是不安全的，瀏覽器會認(rèn)定為“混合內(nèi)容”。

3.2 為什么要阻止混合內(nèi)容？

因?yàn)?HTTP 請求容易被中間人攻擊。
攻擊者可以篡改圖片、注入惡意腳本、或監(jiān)聽請求，從而破壞整個(gè) HTTPS 頁面的安全性。

3.3 混合內(nèi)容的兩種類型

3.4 可升級內(nèi)容（Upgradable Content）

從 Chrome 80+ / Edge 79+ / Firefox 83+ 起，瀏覽器對某些被動混合內(nèi)容啟用了 “自動升級機(jī)制”。
當(dāng)頁面是 HTTPS 時(shí)，如果 <img> 的地址是 HTTP，瀏覽器會嘗試自動改為 HTTPS 重新加載。

3.4.1 舉例說明：

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

瀏覽器會自動嘗試請求：

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

如果資源服務(wù)器支持 HTTPS，就會成功顯示。
如果不支持或證書無效，加載失敗（顯示裂圖）。

注意瀏覽器在 network 面板請求的是 https 請求，但是 DOM 中還是現(xiàn)實(shí)的 http 地址，瀏覽器可不會自動修改你的 DOM。

那么問題來了，為啥 DOM 沒變但是渲染的是 https？

因?yàn)?nbsp;請求完成后，瀏覽器渲染的是“響應(yīng)的二進(jìn)制內(nèi)容”，不是 URL

圖片 <img> 加載流程其實(shí)是：

1. DOM 給出 URL 字符串（http）

2. Resource Loader 把它升級成 https 并發(fā)送請求

3. 請求返回后產(chǎn)生一個(gè) decoded image bitmap（解碼好的位圖）

4. <img> 標(biāo)簽?zāi)玫降氖?“圖片數(shù)據(jù)對象”（Image Bitmap / Image Document）

5. 把這個(gè) bitmap 交給渲染引擎繪制在頁面上

也就是說，渲染用的不是 URL，而是“圖片數(shù)據(jù)”

3.4.2 瀏覽器不會把< img  src=""> 改成 https

因?yàn)?URL 升級只是加載規(guī)則（fetching rule）的結(jié)果，不是文檔結(jié)構(gòu)(DOM) 的改變。

瀏覽器的設(shè)計(jì)理念：

• DOM = 你的代碼

• Loaders = 瀏覽器的行為

瀏覽器永遠(yuǎn)不會篡改你的 DOM 代碼，只在加載階段更換 URL。

3.5 哪些資源屬于“可升級內(nèi)容”

?? 官方文檔參考：
MDN: 混合內(nèi)容（Mixed Content）

3.6 注意：不是“所有場景”都自動升級

• 升級依賴瀏覽器支持；

• 如果資源使用了 IP、非標(biāo)準(zhǔn)端口或證書無效，不會升級；

• 如果頁面設(shè)置了 CSP：

• Content-Security-Policy: upgrade-insecure-requests
  

• 則會強(qiáng)制所有 HTTP 請求都升級為 HTTPS

• 升級失敗依然會導(dǎo)致裂圖。

3.7 為什么以前的說法是“不會自動改為 https”

因?yàn)樵?Chrome 80 之前（2020 年以前），瀏覽器并不具備“自動升級”行為，只是警告或阻止。
現(xiàn)在的混合內(nèi)容機(jī)制是新一代瀏覽器安全策略的演進(jìn)結(jié)果。

3.8 HTTP 頁面加載 HTTPS 圖片會怎樣？

不會觸發(fā)混合內(nèi)容，HTTP 頁面加載 HTTPS 圖片完全合法，只是頁面本身不安全。

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

4.1 跨域限制（Canvas 繪制）

若 <img> 跨域加載資源后再畫到 <canvas> 上，未設(shè)置 crossorigin 會觸發(fā)安全限制。

4.2圖片過大或加載超時(shí)

大圖未能在超時(shí)時(shí)間內(nèi)返回，可能表現(xiàn)為裂圖。

4.3服務(wù)端緩存頭異常

過期或 ETag 不匹配，導(dǎo)致 CDN 無法正確命中圖片。

五、排查與修復(fù)建議

六、總結(jié)

混合內(nèi)容機(jī)制是現(xiàn)代瀏覽器為保證 HTTPS 安全性而做出的妥協(xié)與平衡。

對于前端開發(fā)者而言，理解它的升級與阻止邏輯，是解決“裂圖”的關(guān)鍵。

到此這篇關(guān)于前端圖片加載失敗、 img出現(xiàn)裂圖的原因超詳細(xì)解析的文章就介紹到這了,更多相關(guān)前端圖片加載失敗原因內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論