大家好，我是魚皮，這兩天又發生了一件挺意外的事：Gitee 的圖床廢了！
圖床：指儲存圖片的伺服器，方便在網路上展示圖片
昨天晚上，星球裡不只一位小夥伴發貼文表示自己網站、文章中的圖片竟然全部變成了Gitee 的圖標？ ！
我當時還不了解真相，心想 Gitee 這麼大的程式碼開源平台也能掛？就問小夥伴怎麼回事：
我想，如果是官方的問題，那肯定很多用 Gitee 來做圖床的專案文件都會受到影響。於是我就去 GitHub 上隨便搜了幾個項目，果不其然，很多項目文檔裡的圖示都變成了 Gitee。
千萬別小看這個事情的影響！一方面是鬧了不少笑話，例如下圖這個專案的贊助商，都變成了Gitee：
還有一些作者的引流、打賞二維碼清一色都變成了Gitee 圖標，這就直接影響到作者的收入了！ （一天了，作者還沒發現，請大家廣而告之~）
還有同學的部落格變成了這樣。 。 。
於是我先去網路簡單調研了一下，有不少小夥伴都遇到了這個問題，那估計就是官方的鍋子了。
然後我進入Gitee，找到自己之前搭建的圖床倉庫（專門用來存放圖片的代碼倉庫），隨便找到一張圖片，先進入圖片查看頁（路徑包含blob），然後點擊原始資料查看原圖：
透過跳轉的方式是能夠順利開啟圖片的（原圖頁面的位址不包含blob）：
然後我直接複製圖片的位址，重新整理頁面，結果就看不到圖片了。按F12 來監聽網路請求，發現圖片請求並沒有得到正確的回應，反而得到了一個favicon.ico：
猜一猜就知道了，這個ico 文件果然就是Gitee 的圖示！
那為什麼從 Gitee 自己的頁面跳到真實圖片位址就能顯示出圖片，直接存取位址就會被攔截呢？
顯然是Gitee 為圖片添加了防盜鏈，一般情況下，服務端會從客戶端的請求頭中讀取Referer，透過判斷referer 頭是否在白名單中，來決定正常響應圖片還是攔截。
為了驗證這一點，再做個實驗。先用Firefox 瀏覽器直接開啟Gitee 圖片的真實位址，果然無法顯示：
然後我們在F12 開發者工具中找到剛剛的圖片要求，點擊編輯並重發：
然後給先前的請求補充上一個Referer，表示從哪個頁面跳到了目標頁面：
對於目前已經受Gitee 影響的小夥伴，可以做以下幾件事：
#找到新的物件儲存服務
把Gitee 倉庫的程式碼打包下載並完整上傳到新的物件儲存服務中（保證路徑一致）
#使用文字編輯器將圖片的連結前綴（gitee.com/xxx）批量替換成新的儲存服務連結前綴
#唉，想想都很麻煩。 。 。所以條件允許的話，還是建議大家把圖片存到自己的伺服器（物件儲存服務），更安全放心一些。
教學推薦：《Git教學》
