先交代一個(gè)場(chǎng)景你的C#項(xiàng)目里放了一個(gè)PictureBox用來顯示產(chǎn)品圖片開發(fā)機(jī)上跑得好好的結(jié)果同事clone下來一點(diǎn)開圖片碎了一地。你問他怎么回事他說“倉庫里根本沒看見那幾張圖”。再一看你的.git目錄已經(jīng)膨脹到幾百M(fèi)B提交記錄里躺著幾十張被人來回改過136遍的設(shè)計(jì)稿。這還不算完ci拉代碼越來越慢最后整個(gè)倉庫像得了動(dòng)脈硬化一樣push一次卡半天。如果你也遇到過這種事那這篇文章就是寫給你的。PictureBox本身只是個(gè)顯示控件問題從來不出在它身上而是出在它背后那堆圖像文件怎么進(jìn)、怎么存、怎么被版本控制對(duì)待。說白了圖片文件跟Git倉庫的關(guān)系特別像戀愛——你不好好經(jīng)營(yíng)它就會(huì)用各種方式“背叛”你。今天我把這些年踩過的坑、試過的辦法、最后留下的組合拳全部攤開講從原理到實(shí)操從配置到清理一次講透。1. 圖像文件是怎么一步步“毀掉”Git倉庫的先別急著配.gitignore得先搞明白為什么圖片文件對(duì)Git特別不友好。很多人以為“文件大就是問題”其實(shí)這不全面文本文件再大Git也能處理得游刃有余真正讓Git抓狂的是二進(jìn)制文件而圖片正是二進(jìn)制文件的典型代表。1.1 快照機(jī)制Git到底是怎么存文件的Git的存儲(chǔ)邏輯跟SVN那套“記錄差異”的傳統(tǒng)版本控制完全不同。SVN關(guān)心的是“這一行跟上一版比改了什么”Git則更粗暴——每次commit都生成一個(gè)快照把當(dāng)前所有文件的完整內(nèi)容打一個(gè)包存下來。聽起來好像Git更費(fèi)空間對(duì)吧但Git有層去重機(jī)制每個(gè)文件內(nèi)容都會(huì)被計(jì)算成SHA-1哈希值如果兩次commit之間某個(gè)文件沒變那第二次快照直接復(fù)用第一個(gè)版本的blob對(duì)象不會(huì)額外占空間。這套機(jī)制對(duì)文本文件很友好因?yàn)槲谋緝?nèi)容的復(fù)用率極高。但圖片是另一回事——PNG、JPG這類格式本身就是壓縮過的哪怕你只是把一張800×600的圖片調(diào)了一下亮度重新保存后文件內(nèi)容的字節(jié)流幾乎全是新的哈希值變了Git就會(huì)老老實(shí)實(shí)把整張圖當(dāng)新對(duì)象堆進(jìn)倉庫。團(tuán)隊(duì)里如果有個(gè)人有事沒事改兩筆設(shè)計(jì)稿三個(gè)月下來那個(gè)圖就“繁殖”出了幾十個(gè)互不相同的完整副本。1.2 二進(jìn)制文件的死穴diff、merge全瞎了Git的diff和merge機(jī)制本質(zhì)上是基于行文本的。文本文件改一行Git能精準(zhǔn)告訴你“第42行變了從A變成B”但二進(jìn)制文件在Git眼里就是一串無意義的字節(jié)流它只能做到“這個(gè)文件變了”卻說不清“哪里變了”。于是會(huì)發(fā)生兩件讓人血壓飆升的事。第一件事代碼沖突時(shí)Git還能自動(dòng)合并圖片沖突時(shí)Git直接躺平你只能二選一要么保留我的要么保留你的沒有任何中間地帶。設(shè)計(jì)師那邊剛更新了按鈕背景圖你這邊又從舊分支合了一個(gè)版本過來兩個(gè)人各自存了一份合并的時(shí)候要么覆蓋對(duì)方要么你自己手動(dòng)拿圖對(duì)比著挑純粹靠肉眼和運(yùn)氣。第二件事pull request的review體驗(yàn)?zāi)懿畹侥阆肓R人。正常的代碼改動(dòng)reviewer能看diff、能逐行評(píng)論圖片文件呢Git只能顯示“這個(gè)二進(jìn)制文件有改動(dòng)”想看詳情只能額外下載一份對(duì)比工具。如果你的PR里順手改了十幾張圖標(biāo)光看diff就夠你喝一壺的更別提這些沒意義的變化還會(huì)拉低整個(gè)倉庫的協(xié)作效率。我在某個(gè)項(xiàng)目里就見過真實(shí)的翻車現(xiàn)場(chǎng)——一個(gè)模擬項(xiàng)目X的C#客戶端界面上一堆縮略圖直接從同事電腦里拖進(jìn)項(xiàng)目文件夾然后順手就commit了。其中有張主界面背景圖被不同人前前后后改了二十幾版每一版都完整保留在Git歷史里。最后倉庫體積超過2GBclone一次要用十幾分鐘新同事入職第一天就卡在拉代碼這一步。這還算是運(yùn)氣好的另一個(gè)更極端的例子里有人不小心把一段高清視頻素材commit進(jìn)了倉庫擦掉它比把它放進(jìn)去難十倍——后面會(huì)細(xì)講怎么“逆天改命”。2. 圖片資源的五種“相處模式”選對(duì)才能長(zhǎng)久知道問題之后核心就變成一件事圖片到底應(yīng)該跟倉庫保持什么關(guān)系我梳理了平時(shí)最常見的五種處理方式每一種都有它的適用場(chǎng)景也有它的坑。選對(duì)方式比會(huì)配置命令重要得多。2.1 本地路徑直接引用最方便但最危險(xiǎn)剛寫C#的時(shí)候大家最習(xí)慣的做法就是選中PictureBox在屬性面板里找到Image然后點(diǎn)開文件對(duì)話框選擇本地磁盤上的圖片。舒服是真舒服幾秒鐘搞定但隱患特別大。這種方式生成的代碼通常是這樣的pictureBox1.Image Image.FromFile(D:\素材中心\產(chǎn)品圖\box.png); pictureBox1.SizeMode PictureBoxSizeMode.Zoom;看著沒什么問題實(shí)際上這是一顆定時(shí)炸彈。為什么第一路徑寫死了D盤同事的機(jī)器上根本沒有這個(gè)路徑第二就算你改成相對(duì)路徑圖片文件也不在你的項(xiàng)目目錄里根本不會(huì)被版本控制跟蹤第三運(yùn)行目錄如果發(fā)生了變化路徑同樣會(huì)失效。結(jié)果就是代碼能clone、能編譯但一運(yùn)行圖片就是空的跑起來的那一刻你都不知道該罵自己還是罵環(huán)境。我的建議很簡(jiǎn)單永遠(yuǎn)不要用絕對(duì)路徑加載圖片。本地預(yù)覽可以但無論什么情況這個(gè)代碼都不能進(jìn)入正式倉庫。PictureBox的圖片最終要么來自項(xiàng)目?jī)?nèi)的相對(duì)路徑要么來自資源文件要么來自外部存儲(chǔ)絕不該來自某臺(tái)具體電腦上的某個(gè)目錄。2.2 直接拷貝到項(xiàng)目目錄看似正常實(shí)則埋雷比本地路徑稍微靠譜一點(diǎn)的做法是把圖片復(fù)制到項(xiàng)目文件夾里比如放到Images目錄下然后用相對(duì)路徑加載pictureBox1.Image Image.FromFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Images, box.png));這種做法的好處是圖片跟著項(xiàng)目走提交到Git以后大家都能拿到。但問題來了——圖片被Git跟蹤以后前面說的倉庫膨脹、二進(jìn)制diff、圖片沖突一個(gè)都不會(huì)少。如果項(xiàng)目里只有一兩張小圖標(biāo)還好一旦有幾十張幾百張用戶上傳的產(chǎn)品圖或者設(shè)計(jì)稿倉庫體積立刻失控。這還不是最坑的。圖片文件還有“運(yùn)行時(shí)行為”圖片被程序引用的時(shí)候文件是處于鎖定狀態(tài)的你想在項(xiàng)目運(yùn)行的時(shí)候替換圖片根本覆蓋不了會(huì)報(bào)“文件正在被另一進(jìn)程使用”。另外還得關(guān)心圖片的CopyToOutputDirectory屬性設(shè)置成Copy always還是Copy if newer。很多新人不懂設(shè)成Copy always以后每次編譯都強(qiáng)制拷貝一遍幾十張圖幾百M(fèi)B編譯速度肉眼可見地變慢。我自己實(shí)測(cè)過編譯時(shí)間從幾秒變成幾十秒這種感覺就像開著拖拉機(jī)過彎——能走但賊難受。2.3 Resources資源文件小而穩(wěn)的“良配”如果你用的圖片是固定不變的界面元素——按鈕圖標(biāo)、Logo、默認(rèn)頭像、背景圖——那我強(qiáng)烈推薦把圖片放進(jìn)Resources里。操作不復(fù)雜項(xiàng)目屬性 → 資源 → 添加資源 → 添加現(xiàn)有文件選圖進(jìn)來。這種方式的好處是圖片會(huì)被編譯進(jìn)程序集隨程序一起分發(fā)不需要額外帶一堆文件。運(yùn)行時(shí)也不需要操心底層圖片有沒有被誤刪、路徑對(duì)不對(duì)因?yàn)樵诖a里引用它根本不需要路徑。pictureBox1.Image Properties.Resources.product_placeholder;加粗的那個(gè)代碼直接通過強(qiáng)類型資源訪問編譯器的智能提示都能找到它如果資源不存在編譯期就報(bào)錯(cuò)了根本輪不到運(yùn)行時(shí)出洋相。對(duì)C#開發(fā)來說只要是“固定數(shù)量、固定用途”的圖片Resources永遠(yuǎn)是我的首選。但Resource也有它的邊界。第一程序集體積會(huì)變大一張高清圖放進(jìn)去整個(gè)exe的體積就上去了注意控制圖片尺寸和格式盡量用PNG別塞一堆沒壓縮的BMP第二如果你需要“運(yùn)行時(shí)替換圖片”或者“支持用戶上傳圖片”靠Resources是玩不轉(zhuǎn)的它更適合靜態(tài)資源。2.4 嵌入式資源適合圖標(biāo)級(jí)小圖比Resources更“硬核”的做法是把圖片作為Embedded Resource嵌入到程序集里然后通過反射讀取。這種方案適合插件式架構(gòu)或者程序集被動(dòng)態(tài)加載的場(chǎng)景。private Image LoadEmbeddedImage(string resourceName) { var assembly Assembly.GetExecutingAssembly(); using var stream assembly.GetManifestResourceStream(resourceName); return stream null ? null : Image.FromStream(stream); }注意resourceName的格式是“命名空間.文件名”寫得不對(duì)會(huì)返回null。實(shí)操中我建議先打印assembly.GetManifestResourceNames()看完整列表再寫代碼別憑感覺猜路徑。圖片文件最好設(shè)置成“生成操作嵌入的資源”不要設(shè)成Resource。我在某個(gè)跨平臺(tái)系統(tǒng)里用過這種方案當(dāng)時(shí)是為了把一組內(nèi)置圖標(biāo)跟主程序打包又能讓不同模塊通過動(dòng)態(tài)鏈接庫加載各自的圖標(biāo)。好處是徹底不依賴外部文件壞處是圖片更新起來比Resources還繁瑣——改一張圖就得重新編譯整個(gè)程序集。所以這個(gè)方案只適合圖標(biāo)、小尺寸占位圖這類基本不動(dòng)的東西。2.5 外部存儲(chǔ)大量動(dòng)態(tài)圖片的最終歸宿如果你的項(xiàng)目里要展示的圖片根本是動(dòng)態(tài)的——用戶上傳的商品圖、后臺(tái)配置的輪播圖、實(shí)時(shí)生成的報(bào)表截圖——那這些圖就和C#程序本身關(guān)系不大它們應(yīng)該被放在“外部”獨(dú)立的文件服務(wù)器程序通過HTTP訪問對(duì)象存儲(chǔ)服務(wù)帶CDN加速甚至是大容量共享盤。程序側(cè)的做法是在PictureBox里加載遠(yuǎn)程圖片// 簡(jiǎn)單示例實(shí)際項(xiàng)目中建議加緩存和超時(shí)控制 pictureBox1.LoadAsync(https://example.com/images/box.png);這個(gè)方向的優(yōu)點(diǎn)是倉庫徹底干凈程序只是消費(fèi)圖片的入口圖片再多、再頻繁更新Git倉庫的體量都紋絲不動(dòng)。缺點(diǎn)是依賴網(wǎng)絡(luò)而且要做本地緩存策略、離線兜底方案幀成本比本地資源高不少。對(duì)以圖片為主營(yíng)業(yè)務(wù)的項(xiàng)目來說這幾乎是唯一的路。3. 實(shí)操給倉庫裝上“安全護(hù)欄”方案定了接下來才是動(dòng)手環(huán)節(jié)。這里說的“動(dòng)手”不是說寫C#代碼而是把版本控制層面的工作做到位。目標(biāo)有三個(gè)讓不該進(jìn)來的圖片待在門外讓必須進(jìn)來的圖片走特殊通道以及把已經(jīng)入倉的歷史包袱清出去。3.1 .gitignore把不速之客擋在門外Git倉庫的第一道防線是.gitignore。它是個(gè)文本文件寫清楚哪些路徑和模式不要被Git跟蹤。很多人只會(huì)在里面寫bin和obj但如果你使用的是方案2.1和2.2的組合那你應(yīng)該把項(xiàng)目中所有容易被誤提交的二進(jìn)制素材目錄也加進(jìn)去。我給你一個(gè)實(shí)際項(xiàng)目比較穩(wěn)妥的模板你可以根據(jù)自己目錄結(jié)構(gòu)調(diào)整# VS 生成目錄 bin/ obj/ .vs/ # 本地圖片素材不入庫 DesignAssets/ RawImages/ *.psd *.ai *.tif # 運(yùn)行時(shí)生成的圖片緩存 Cache/ *.cache這里有幾個(gè)容易踩的坑。第一.gitignore只對(duì)“尚未被跟蹤”的文件生效。如果某個(gè)圖片之前已經(jīng)被git add進(jìn)倉庫了你再在.gitignore里寫出它的路徑也沒用——Git照樣持續(xù)跟蹤它。要讓它不被跟蹤得先執(zhí)行g(shù)it rm --cached DesignAssets/ -r注意--cached只是把文件從索引里移除不會(huì)刪除你本地硬盤上的文件這屬于標(biāo)準(zhǔn)操作可以放心執(zhí)行。之后再加進(jìn).gitignore這個(gè)路徑才算真正跟倉庫徹底撇清關(guān)系。第二.gitignore的模式匹配規(guī)則經(jīng)常有人搞混。比如你寫Images/代表忽略所有叫Images的目錄你寫*.png代表忽略所有png文件但如果你寫了Images/*.png它只會(huì)忽略Images目錄下的png不會(huì)遞歸到子目錄。想遞歸忽略所有目錄下的png直接寫*.png就行。這一點(diǎn)我見過無數(shù)人寫錯(cuò)結(jié)果子目錄的圖片還是漏進(jìn)了倉庫。3.2 使用 Git LFS管理必須入庫的圖片如果你的團(tuán)隊(duì)還堅(jiān)持要把一部分圖片納入版本控制——比如設(shè)計(jì)師的原稿、成體系的UI切圖——那我建議至少給它們“走特殊通道”用Git LFSLarge File Storage接管。LFS的核心思路是把大文件的真實(shí)內(nèi)容存到LFS服務(wù)器上Git倉庫里只存一個(gè)體積極小的指針文件。這樣倉庫本身不會(huì)膨脹clone的時(shí)候只拉指針需要用到具體文件時(shí)再按需下載。對(duì)協(xié)作關(guān)系來說它相當(dāng)于一種“代理模式”——你不直接跟大文件談戀愛而是通過中間人傳遞。裝起來很簡(jiǎn)單。先裝Git LFS客戶端然后在倉庫里執(zhí)行g(shù)it lfs install git lfs track *.png git lfs track *.jpg執(zhí)行完你會(huì)發(fā)現(xiàn)倉庫里多了個(gè).gitattributes文件這是LFS自動(dòng)生成的它記錄了哪些文件類型不走普通Git存儲(chǔ)建議跟代碼一起提交。然后正常add、commit、push就行g(shù)it add design/ .gitattributes git commit -m design assets tracked via LFS git push origin main前端后端的協(xié)作里這種做法特別常見我見過很多團(tuán)隊(duì)用LFS管理Unity、Unreal這類大型照片級(jí)渲染項(xiàng)目。它有幾個(gè)重點(diǎn)需要盯住團(tuán)隊(duì)里所有人必須都裝git lfs不然克隆倉庫后只會(huì)拿到指針文件打不開真實(shí)圖片。LFS有額度限制免費(fèi)服務(wù)期每個(gè)月的存儲(chǔ)流量是有限的別把全公司的設(shè)計(jì)稿一股腦倒進(jìn)去得一邊用一邊盯著流量消耗。LFS追蹤規(guī)則要少而精不要隨手git lfs track *那樣任何二進(jìn)制文件包括視頻、壓縮包全都會(huì)被塞進(jìn)去流量消耗極快。3.3 誤提交后的清理git filter-repo實(shí)操最麻煩的情況是某人不小心把一個(gè)大圖片甚至一段視頻commit進(jìn)了歷史。這時(shí)候就算你刪除文件再提交之前的Git歷史記錄里依然保留著這個(gè)文件的原始對(duì)象倉庫體積并不會(huì)變小。這就好比前任留下的照片你刪了相冊(cè)里的副本但云備份里還全都在。要徹底清理必須重寫歷史。我推薦用git filter-repo這貨是官方推薦用來替代git filter-branch的工具——后者又慢又容易把歷史搞得一團(tuán)糟。以下是完整步驟。首先確認(rèn)你已經(jīng)安裝了Python環(huán)境然后pip install git-filter-repo接著在倉庫目錄執(zhí)行清理命令刪除所有歷史中名為big_video.mp4的文件git filter-repo --path big_video.mp4 --invert-paths如果你要按路徑清理一個(gè)目錄比如Assets/RawImages/就改成git filter-repo --path Assets/RawImages/ --invert-paths--invert-paths的意思就是“排除這些路徑”也就是說除了指定路徑外保留其他所有內(nèi)容。執(zhí)行完后Git歷史會(huì)被完整重寫那個(gè)文件的影子徹底消失。注意這一步會(huì)改變所有提交的哈希值已經(jīng)clone到別人本地的倉庫全部變成舊版本必須重新clone或者強(qiáng)制同步。在團(tuán)隊(duì)協(xié)作的時(shí)候你得提前通知所有人“歷史重寫了把本地倉庫刪掉重新clone”別用git pull硬拉否則會(huì)拉出一個(gè)新舊分支交織的怪物。然后再用git gc --prunenow --aggressive壓縮對(duì)象存儲(chǔ)把懸空對(duì)象徹底清空。最后push的時(shí)候因?yàn)闅v史全部改變了需要強(qiáng)制推送比如git push origin master --force如果團(tuán)隊(duì)有其他人在push上游代碼務(wù)必先鎖定上游倉庫避免中途被人推送新對(duì)象導(dǎo)致清理不干凈。這步操作我一般選在深夜加班時(shí)干至少把所有同事的提交都停掉不然數(shù)據(jù)會(huì)被“污染”回去。4. 常見問題排查與避坑手記理論上前面幾節(jié)的內(nèi)容足夠搭建一個(gè)健康的圖片管理方案了但理論歸理論實(shí)操中總會(huì)冒出各種意外。我把這些年忙活過的項(xiàng)目和見過的真實(shí)案例里最經(jīng)典的問題整理成速查表順便附上我的排查思路。4.1 高頻問題速查表問題現(xiàn)象直接原因處理方式clone倉庫慢體積幾百M(fèi)B甚至幾GB倉庫里堆積了大量二進(jìn)制歷史對(duì)象用filter-repo清理后gc或改用LFS同事clone下來運(yùn)行圖片全部空白代碼用了絕對(duì)路徑/資源未入庫改成Resources或者項(xiàng)目?jī)?nèi)相對(duì)路徑圖片在本地運(yùn)行正常發(fā)布后丟了CopyToOutputDirectory沒設(shè)置屬性改成Copy if newer并檢查發(fā)布配置修改圖片后編譯越來越慢圖片被設(shè)為Copy always強(qiáng)制拷貝改成Copy if newer或者圖片入ResourcesPR里看圖片看不到具體改動(dòng)Git對(duì)二進(jìn)制文件只能判定內(nèi)容變化約定圖片改動(dòng)由設(shè)計(jì)師說明或用外部對(duì)比工具運(yùn)行程序時(shí)無法覆蓋替換圖片文件被程序鎖定占用關(guān)掉程序再替換或使用Resources替代直接文件引用團(tuán)隊(duì)里沒人裝LFS圖片顯示為指針文件LFS指針和真實(shí)內(nèi)容分離全隊(duì)統(tǒng)一安裝git lfs并重新拉取這張表覆蓋的范圍基本就是我在實(shí)際項(xiàng)目里被問得最多的“為什么圖片又出問題了”。大部分問題都不是C#代碼的bug而是項(xiàng)目倉儲(chǔ)策略沒有在最早定清楚。4.2 排查實(shí)錄三次真實(shí)翻車場(chǎng)景第一個(gè)場(chǎng)景發(fā)生在某個(gè)模擬項(xiàng)目X的開發(fā)過程中。某天早上所有同事反映克隆倉庫要將近二十分鐘我拉下來一看du -sh一數(shù)光.git目錄就將近800MB。再按文件大小排了個(gè)序發(fā)現(xiàn)最大的幾個(gè)文件全是某位同事本地放著的設(shè)計(jì)底稿他把整個(gè)DesignAssets目錄一股腦add進(jìn)去了這里面有幾十張PSD源文件每張動(dòng)輒幾十MB。因?yàn)檫@些PSD后來還被反復(fù)修改提交倉庫體積像一個(gè)吹爆了的氣球。最終我用filter-repo把所有PSD和DesignAssets路徑清理干凈然后調(diào)整.gitignore、命令團(tuán)隊(duì)以后原稿一律放共享盤倉庫體積瞬間縮回幾十MB。第二個(gè)場(chǎng)景是發(fā)布之后圖片丟失。程序本地跑得好好的一發(fā)布的服務(wù)器上就顯示空白圖。排查了半天發(fā)現(xiàn)用戶的運(yùn)行目錄下根本沒有該圖片文件因?yàn)殚_發(fā)時(shí)代碼寫的是相對(duì)路徑但文件屬性沒有配置Copy to Output Directory導(dǎo)致編譯發(fā)布以后圖片文件沒有被拷貝到輸出目錄。這個(gè)問題的根因不是圖片沒提交而是構(gòu)建配置沒跟上后來統(tǒng)一改成Resources資源引用再也沒出過同類問題。第三個(gè)場(chǎng)景稍微隱蔽一點(diǎn)圖片文件本身沒丟但git pull以后一直報(bào)“二進(jìn)制文件沖突”把整個(gè)分支合并卡了一個(gè)下午。原因是有兩個(gè)同事分別改了同一張界面背景圖其中一個(gè)本地提交之后推上去另一個(gè)拉取時(shí)本地也有未提交的修改結(jié)果文件被鎖merge直接炸掉。我的處理辦法是把背景圖改成從外部配置讀取程序啟動(dòng)的時(shí)候從指定目錄加載如果加載失敗才用Resources里的默認(rèn)圖兜底。這樣既不影響倉庫清潔度也避免了多人同時(shí)改一張圖的死鎖。4.3 我的最終推薦組合與習(xí)慣養(yǎng)成嚴(yán)格來說沒有一套方案能適配所有項(xiàng)目但我個(gè)人摸索出的一套組合拳已經(jīng)在我多個(gè)C#項(xiàng)目里穩(wěn)定跑了好幾年你可以直接拿去參考界面固定圖標(biāo)、Logo、默認(rèn)圖放Resources。優(yōu)點(diǎn)是編譯期檢查、打包省事、運(yùn)行時(shí)零依賴。用戶上傳圖片、動(dòng)態(tài)內(nèi)容圖片不入庫傳給文件服務(wù)器或?qū)ο蟠鎯?chǔ)。程序只要保存URL或圖片ID本地永遠(yuǎn)不留原始圖。設(shè)計(jì)師原稿、大體積PSD/無損源文件一律不進(jìn)Git倉庫都由共享網(wǎng)盤承載。如果協(xié)作有交叉改用LFS跟蹤并對(duì)每個(gè)文件的大小和數(shù)量設(shè)定紅線比如單文件超過20MB必須請(qǐng)示。運(yùn)行時(shí)生成的臨時(shí)圖片寫入程序運(yùn)行緩存目錄比如Path.GetTempPath()或AppContext.BaseDirectory/cache并在.gitignore里排除。如果某些圖片一定要在Git里追蹤必須走LFS并且定期檢查倉庫體積超過1GB就啟動(dòng)清理流程。至于代碼側(cè)的習(xí)慣每次要寫Image.FromFile的時(shí)候先停下兩秒鐘問自己文件路徑真的可靠嗎要不要改成Resources這兩秒鐘能省下后面一整天的排查時(shí)間。最后再分享一個(gè)我覺得特別實(shí)用的小技巧在C#項(xiàng)目里如果只是需要一張空白占位圖或者需要一個(gè)純色背景沒必要去網(wǎng)上找圖片文件直接用代碼生成就行了。整個(gè)Bitmap對(duì)象填上顏色賦值給PictureBox這樣做既省了倉庫空間又免了文件依賴代碼還自解釋。var bmp new Bitmap(128, 128); using (var g Graphics.FromImage(bmp)) { g.Clear(Color.SteelBlue); } pictureBox1.Image bmp;注意用完記得Dispose不然內(nèi)存泄漏會(huì)找上你。我做過的項(xiàng)目里凡是早期就把圖片資源和版本控制關(guān)系理清楚后續(xù)維護(hù)都順順利利凡是懶得管、抱著“先跑起來再說”心態(tài)的幾乎無一例外都要在大倉庫、圖片丟失、沖突爆炸這三個(gè)坑里輪滾一遍。PictureBox只是個(gè)控件真正的“戀愛法則”是背后的資源管理意識(shí)——平時(shí)約束好自己關(guān)鍵時(shí)刻才不會(huì)翻車。希望你從今天起也能讓你的Git倉庫對(duì)圖片文件保持一份“忠誠”。