FDE 又不夠了。這里的 FDE 指的是前端開(kāi)發(fā)環(huán)境Frontend Development Environment不是 Android 全盤(pán)加密。前端工程師、全棧開(kāi)發(fā)者、以及所有在本地同時(shí)維護(hù)多個(gè)項(xiàng)目的同學(xué)大概率都經(jīng)歷過(guò)同一個(gè)場(chǎng)景C 盤(pán)或者 Mac 的硬盤(pán)條突然變紅Docker 拉不動(dòng)鏡像npm install 直接報(bào) ENOSPC日志文件刷得飛快。排查一圈之后發(fā)現(xiàn)罪魁禍?zhǔn)撞皇谴a本身而是開(kāi)發(fā)環(huán)境里的緩存、依賴和鏡像把磁盤(pán)吃干凈了。這篇文章不聊崗位梗只聊怎么把磁盤(pán)從爆滿狀態(tài)里救回來(lái)。核心內(nèi)容包括先用工具和命令快速定位空間占用大戶再按照項(xiàng)目依賴、包管理器緩存、Docker 鏡像、系統(tǒng)日志四個(gè)維度分別清理最后給出防止 FDE 再次爆滿的長(zhǎng)期策略。文章里所有命令都是通用方案適用于 Windows、macOS 和 Linux讀者可以直接復(fù)制到自己的環(huán)境里驗(yàn)證。如果你是那種本地裝了一堆 node_modules、Docker 鏡像、Electron 緩存還順便跑過(guò)幾個(gè)開(kāi)源 AI 模型的開(kāi)發(fā)者這篇文章建議直接收藏。下面進(jìn)入正題。1. 核心能力與磁盤(pán)占用來(lái)源速覽先給一張速覽表把 FDE 磁盤(pán)爆滿最常見(jiàn)的幾個(gè)來(lái)源、典型位置和處理方式列清楚。實(shí)際占用大小會(huì)因項(xiàng)目和系統(tǒng)差異很大不要照搬數(shù)字重點(diǎn)是知道去哪里找。占用來(lái)源常見(jiàn)位置典型特征清理手段風(fēng)險(xiǎn)等級(jí)node_modules各項(xiàng)目根目錄單個(gè)幾十 MB 到幾 GB項(xiàng)目越多越夸張刪除后重新 install低可恢復(fù)pnpm/npm/yarn 緩存用戶目錄下 .npm、.cache、Library/Caches常年累積動(dòng)輒 10 GB 以上包管理器自帶 clean/prune低可恢復(fù)Docker 鏡像與構(gòu)建緩存Docker 數(shù)據(jù)目錄Linux 默認(rèn) /var/lib/docker鏡像、懸空層、build cache 體積巨大docker system prune中需確認(rèn)鏡像用途Docker 容器日志/var/lib/docker/containers/高頻服務(wù)日志能漲到幾十 GB限制日志大小或清空中影響排障Electron/Chromium 緩存用戶緩存目錄多個(gè) Electron 應(yīng)用各占一份直接刪緩存目錄低系統(tǒng)日志/var/log、C:\Windows\Temp、/tmp日志文件長(zhǎng)期不輪轉(zhuǎn)logrotate 清理低Git 對(duì)象歷史項(xiàng)目 .git 目錄大二進(jìn)制文件提交后殘留git gc / 重寫(xiě)歷史較高需謹(jǐn)慎本地模型下載緩存~/.cache/huggingface、ComfyUI models 目錄大模型文件單文件數(shù) GB按需保留或轉(zhuǎn)移較高影響離線使用從實(shí)際經(jīng)驗(yàn)看磁盤(pán)爆滿通常不是某個(gè)單一原因而是這幾個(gè)來(lái)源疊加。定位的順序應(yīng)該是先看整體磁盤(pán)分配再逐層下鉆到具體目錄最后判斷哪些能刪、哪些要遷移、哪些必須保留。2. 適用場(chǎng)景與使用邊界這套排查與清理方案適合四類人本地同時(shí)維護(hù)多個(gè)前端項(xiàng)目的工程師被 node_modules 和緩存折騰過(guò)使用 Docker 做本地聯(lián)調(diào)或部署驗(yàn)證鏡像和構(gòu)建緩存常年堆積電腦上裝了 Electron 應(yīng)用、瀏覽器多個(gè) Profile用戶目錄膨脹到無(wú)法忽略順便玩本地 AI 工具或大模型huggingface 緩存和 ComfyUI 模型文件體積巨大。不適合的直接刪除場(chǎng)景也要先說(shuō)清楚。涉及生產(chǎn)服務(wù)器、數(shù)據(jù)庫(kù)文件、私鑰、證書(shū)、未提交的本地分支、依賴鎖定文件不匹配等場(chǎng)景不要照搬一鍵清理命令。清理 Docker 卷時(shí)尤其要謹(jǐn)慎docker system prune -a --volumes會(huì)刪除沒(méi)有被容器使用的匿名卷如果里面有本地?cái)?shù)據(jù)庫(kù)數(shù)據(jù)刪掉就很難恢復(fù)。使用邊界上還要注意數(shù)據(jù)安全和版權(quán)。本地可能有公司內(nèi)部代碼、客戶資料、模型權(quán)重等敏感文件清理前要確認(rèn)歸屬。本文所有命令都建議先打印結(jié)果、再執(zhí)行刪除而不是直接一條命令帶走。3. 環(huán)境準(zhǔn)備與前置檢查清理磁盤(pán)不需要太復(fù)雜的準(zhǔn)備但需要確認(rèn)三件事當(dāng)前磁盤(pán)狀態(tài)、是否存在正在運(yùn)行的服務(wù)、是否有需要備份的關(guān)鍵文件。先看整體磁盤(pán)使用情況。Linux 和 macOS 系統(tǒng)使用 df 命令df -h輸出里會(huì)看到/、/home、/Users等掛載點(diǎn)的使用率和剩余空間。如果使用率已經(jīng)超過(guò) 85%說(shuō)明確實(shí)到了需要?jiǎng)邮值臅r(shí)候。Windows 可以在 PowerShell 里查看Get-PSDrive C | Select-Object Used,Free接下來(lái)確認(rèn) Docker 或者本地開(kāi)發(fā)服務(wù)是否正在運(yùn)行。清理 Docker 相關(guān)資源之前先檢查是否有正在使用的容器docker ps清理之前建議對(duì)關(guān)鍵配置文件做一次備份。特別是package-lock.json、pnpm-lock.yaml、yarn.lock以及 Docker Compose 的.env文件。這些文件體積小但刪錯(cuò)了會(huì)導(dǎo)致依賴無(wú)法鎖定版本或者服務(wù)配置丟失。4. 第一步定位磁盤(pán)空間占用大戶不要憑感覺(jué)刪東西先用工具找出真實(shí)的磁盤(pán)占用分布。Linux 和 macOS 下最直接的方式是 ncdu。它是一個(gè)交互式磁盤(pán)分析工具按目錄大小從大到小展示操作直觀# macOS brew install ncdu # Ubuntu / Debian sudo apt install ncdu # 開(kāi)始掃描當(dāng)前目錄 ncdu /掃描完成之后用鍵盤(pán)方向鍵進(jìn)入目錄按d刪除目標(biāo)目錄按q退出。ncdu 的優(yōu)勢(shì)是可以在交互界面里反復(fù)查看不容易誤刪。如果沒(méi)有 ncdu也可以用 du 和 sort 快速定位# 查看根目錄下各目錄占用取前 20 sudo du -sh /* 2/dev/null | sort -hr | head -20 # 查看當(dāng)前項(xiàng)目里哪個(gè)目錄最大 du -sh * 2/dev/null | sort -hr | head -20Windows 用戶建議使用 WizTree 或 TreeSize。這類工具以 NTFS 的 MFT 直接掃描速度比 PowerShell 遞歸統(tǒng)計(jì)快很多幾秒鐘就能看到整個(gè)磁盤(pán)的占用熱力圖。如果不想裝圖形工具也可以直接在項(xiàng)目目錄里用 PowerShell 統(tǒng)計(jì)Get-ChildItem -Directory | ForEach-Object { $size (Get-ChildItem $_.FullName -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum [PSCustomObject]{ Name $_.Name; SizeMB [math]::Round($size / 1MB, 2) } } | Sort-Object SizeMB -Descending | Select-Object -First 20定位的目標(biāo)是找出占用最高的前三個(gè)目錄然后逐個(gè)判斷是哪種類型是 node_modules、是 Docker 數(shù)據(jù)目錄、還是緩存目錄。定位清楚之后再進(jìn)入對(duì)應(yīng)的清理步驟。5. 第二步清理項(xiàng)目依賴與 node_modulesnode_modules 是前端開(kāi)發(fā)環(huán)境里最招人恨的目錄之一。一個(gè)中等規(guī)模項(xiàng)目依賴裝完動(dòng)輒 500 MB 到 2 GB。如果同時(shí)維護(hù) 10 個(gè)項(xiàng)目就是 5 GB 起步這還不包括 pnpm 的全局 store。清理單個(gè)項(xiàng)目的 node_modules 不難。Linux 和 macOS 直接用 rmrm -rf node_modulesWindows 下 node_modules 經(jīng)常出現(xiàn)路徑過(guò)長(zhǎng)導(dǎo)致刪除失敗的情況可以先用 npx rimraf 處理npx rimraf node_modules刪完之后重新安裝依賴# npm npm install # pnpm pnpm install # yarn yarn這里要強(qiáng)調(diào)一下鎖文件的作用。刪除 node_modules 之前必須確認(rèn)項(xiàng)目根目錄有package-lock.json、pnpm-lock.yaml或yarn.lock。有鎖文件重新安裝后的依賴版本才是可控的沒(méi)有鎖文件重裝之后依賴版本可能飄掉導(dǎo)致項(xiàng)目跑不起來(lái)。如果你用的是 pnpm它還有個(gè)更隱蔽的磁盤(pán)占用點(diǎn)就是全局 store。pnpm 會(huì)把所有依賴包的實(shí)體文件存儲(chǔ)在 store 里項(xiàng)目里的 node_modules 只是硬鏈接或符號(hào)鏈接。所以即使你刪了項(xiàng)目里的 node_modulespnpm store 里的文件也還在。查看和清理方式# 查看 store 位置 pnpm store path # 刪除 store 中未被項(xiàng)目引用的包 pnpm store prunepnpm store prune是安全的它只會(huì)清理沒(méi)有被任何項(xiàng)目引用的包。如果多個(gè)項(xiàng)目共用同一個(gè) store清理后需要重新安裝依賴的項(xiàng)目會(huì)重新從網(wǎng)絡(luò)下載缺失的包但已存在的包仍然復(fù)用。對(duì)于長(zhǎng)期維護(hù)的項(xiàng)目建議從 Yarn 或 npm 切換到 pnpm。pnpm 的依賴存儲(chǔ)方式天然節(jié)省磁盤(pán)同一個(gè)版本的依賴包在全局只保存一份。遷移方式不復(fù)雜刪除 node_modules 后導(dǎo)入鎖文件即可pnpm import package-lock.json pnpm install6. 第三步清理包管理器緩存與構(gòu)建緩存很多開(kāi)發(fā)者的磁盤(pán)爆滿問(wèn)題不只是 node_modules 導(dǎo)致的更常見(jiàn)的是包管理器緩存和構(gòu)建緩存長(zhǎng)期不清理。npm 的緩存存放在用戶目錄下的~/.npm清理命令npm cache clean --forcepnpm 的緩存?zhèn)}庫(kù)回收pnpm store pruneyarn 經(jīng)典版和 Berry 版的緩存清理命令不同# yarn 1.x yarn cache clean # yarn 2/Berry yarn cache clean --all清理這些緩存不會(huì)影響項(xiàng)目運(yùn)行最多只是后續(xù)安裝依賴時(shí)需要重新下載。代價(jià)是網(wǎng)絡(luò)時(shí)間和帶寬風(fēng)險(xiǎn)很低。如果本地使用 Vite、Webpack、Next.js 或 Vue CLI 構(gòu)建項(xiàng)目構(gòu)建緩存也會(huì)占用不少空間。常見(jiàn)位置包括node_modules/.cacheWebpack 和 Vite 都會(huì)在這里寫(xiě)入緩存~/.cache/nextNext.js 構(gòu)建緩存~/.cache/esbuildesbuild 二進(jìn)制和緩存~/.cache/puppeteer、~/.cache/ms-playwright自動(dòng)化測(cè)試瀏覽器緩存。這類緩存可以安全刪除刪除后下次構(gòu)建會(huì)重新生成。以 esbuild 為例很多人不知道 esbuild 會(huì)在~/.cache/esbuild下保存二進(jìn)制文件清理命令rm -rf ~/.cache/esbuildElectron 應(yīng)用的緩存也是個(gè)容易忽略的大頭。Electron 基于 Chromium每個(gè)應(yīng)用在自己的用戶數(shù)據(jù)目錄下保存一份瀏覽器緩存。比如 VS Code、Slack、Discord 這些應(yīng)用的緩存目錄可能各自占用幾百 MB 到幾個(gè) GB。清理時(shí)需要先關(guān)閉應(yīng)用然后刪除對(duì)應(yīng)緩存目錄# macOS 下 VS Code 緩存示例 rm -rf ~/Library/Caches/com.microsoft.VSCode # Linux 下 Electron 通用緩存位置 rm -rf ~/.cache/電子應(yīng)用名Windows 下則位于%APPDATA%\應(yīng)用名\Cache和%LOCALAPPDATA%\應(yīng)用名\Cache。刪除緩存不會(huì)影響賬號(hào)登錄和應(yīng)用功能但應(yīng)用下次啟動(dòng)時(shí)會(huì)重新下載或生成緩存。7. 第四步Docker 鏡像、容器與日志回收如果你的開(kāi)發(fā)環(huán)境里裝了 Docker磁盤(pán)占用一般不會(huì)小。Docker 的問(wèn)題在于它不只是存鏡像還會(huì)積累構(gòu)建緩存、容器讀寫(xiě)層、懸空鏡像和日志文件。先看 Docker 到底占了多少docker system df輸出會(huì)顯示鏡像、容器、本地卷、構(gòu)建緩存的占用匯總。如果BUILD CACHE一欄顯示十幾 GB說(shuō)明構(gòu)建緩存已經(jīng)成為主要占用源。一鍵清理所有未使用的 Docker 資源# 清理懸空鏡像、停止的容器、未使用的網(wǎng)絡(luò) docker system prune # 更激進(jìn)刪除所有未被使用的鏡像、構(gòu)建緩存以及未被容器使用的匿名卷 docker system prune -a --volumesdocker system prune -a --volumes要謹(jǐn)慎使用。它確實(shí)能釋放大量空間但會(huì)刪除沒(méi)有被任何容器使用的鏡像所有構(gòu)建緩存沒(méi)有被容器引用的匿名卷。如果你的本地?cái)?shù)據(jù)庫(kù)跑在 Docker 匿名卷里執(zhí)行這條命令會(huì)直接丟數(shù)據(jù)。更穩(wěn)妥的方式是分步清理先清構(gòu)建緩存再清懸空鏡像最后再?zèng)Q定是否清理卷# 清理構(gòu)建緩存 docker builder prune -a # 清理懸空鏡像 docker image prune -a # 查看卷占用逐個(gè)確認(rèn) docker volume ls容器日志是另一個(gè)容易被忽略的大戶。Docker 默認(rèn)會(huì)把容器標(biāo)準(zhǔn)輸出寫(xiě)到 json-file 日志文件里而且默認(rèn)不限制大小。長(zhǎng)時(shí)間運(yùn)行的容器日志文件可能撐到幾十 GB。查看單個(gè)容器日志文件大小# 找到日志文件位置 docker inspect --format{{.LogPath}} 容器名比較直接的方案是清空現(xiàn)有日志然后配置全局日志上限。清空單個(gè)容器的日志# 以 root 身份執(zhí)行注意容器名需要替換 truncate -s 0 $(docker inspect --format{{.LogPath}} 容器名)更根本的解法是在/etc/docker/daemon.json里配置日志輪轉(zhuǎn){ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }修改配置后需要重啟 Docker 服務(wù)sudo systemctl restart docker這樣配置之后每個(gè)容器的日志單文件最大 50 MB最多保留 3 個(gè)文件可以有效防止日志文件無(wú)限膨脹。8. 第五步系統(tǒng)日志、臨時(shí)文件與本地模型緩存系統(tǒng)層面的臨時(shí)文件和日志也是磁盤(pán)殺手只是它們藏得比較深平時(shí)不會(huì)特意去看。Linux 系統(tǒng)日志默認(rèn)位于/var/log。長(zhǎng)期不清理的話journald的日志能積累到好幾個(gè) GB。查看 systemd journal 占用journalctl --disk-usage限制 journal 大小并清理舊日志# 限制 journal 最大占用 200 MB sudo journalctl --vacuum-size200M # 永久配置 sudo mkdir -p /etc/systemd/journald.conf.d在/etc/systemd/journald.conf.d/size.conf中寫(xiě)入[Journal] SystemMaxUse200M然后重啟 journaldsudo systemctl restart systemd-journald/tmp目錄和用戶臨時(shí)目錄也值得檢查。Linux 下某些服務(wù)會(huì)往/tmp寫(xiě)入臨時(shí)文件如果服務(wù)沒(méi)有自動(dòng)清理會(huì)一直堆積。重啟系統(tǒng)會(huì)清空/tmp但長(zhǎng)期開(kāi)機(jī)的開(kāi)發(fā)機(jī)可能已經(jīng)積累了數(shù) GB 臨時(shí)文件sudo du -sh /tmp 2/dev/null如果本地部署過(guò) AI 工具或大模型還需要檢查模型緩存目錄。huggingface 的默認(rèn)緩存在~/.cache/huggingfaceComfyUI、Stable Diffusion WebUI 的模型目錄通常在項(xiàng)目目錄或~/.cache下。大模型單文件動(dòng)輒 2 GB 到 7 GB模型多的話占用非常可觀。處理方式不是簡(jiǎn)單刪除而是考慮遷移。把模型目錄移動(dòng)到獨(dú)立磁盤(pán)或外置 SSD然后創(chuàng)建軟鏈接指向原路徑# 把模型目錄移動(dòng)到 /data/models mv ~/.cache/huggingface /data/models/huggingface # 創(chuàng)建軟鏈接 ln -s /data/models/huggingface ~/.cache/huggingface這一步需要先關(guān)閉相關(guān)應(yīng)用再操作避免文件被占用導(dǎo)致移動(dòng)失敗。遷移后應(yīng)用仍然顯示模型在原位置但實(shí)際存儲(chǔ)在獨(dú)立磁盤(pán)上不會(huì)擠占系統(tǒng)盤(pán)空間。9. 防止 FDE 再次爆滿的長(zhǎng)期策略清理一次只能救急防止再次爆滿才是關(guān)鍵。長(zhǎng)期策略可以從四個(gè)方向入手。第一統(tǒng)一依賴安裝策略。新項(xiàng)目?jī)?yōu)先使用 pnpm并開(kāi)啟全局 store 共享。團(tuán)隊(duì)協(xié)作時(shí)提交pnpm-lock.yaml統(tǒng)一依賴版本。舊項(xiàng)目如果維護(hù)成本高可以在 CI 里構(gòu)建本地只保留必要的依賴而不是把所有項(xiàng)目都完整 install 一遍。第二給 Docker 設(shè)置資源上限。daemon.json里配置日志輪轉(zhuǎn)后還需要定期執(zhí)行構(gòu)建緩存清理。可以把清理命令寫(xiě)進(jìn)每周計(jì)劃任務(wù)在低峰期自動(dòng)執(zhí)行0 3 * * 1 docker builder prune -a -f docker image prune -a -f但要注意這條 crontab 不會(huì)處理 Docker 卷卷的清理仍然需要人工確認(rèn)。第三建立磁盤(pán)告警。寫(xiě)一個(gè)簡(jiǎn)單的腳本當(dāng)磁盤(pán)使用率超過(guò)閾值時(shí)提醒自己。以 Linux 為例#!/usr/bin/env bash threshold85 usage$(df / | awk NR2 {print $5} | tr -d %) if [ $usage -ge $threshold ]; then echo [$(date)] 磁盤(pán)使用率 ${usage}%請(qǐng)檢查以下目錄 du -sh ~/.npm ~/.cache /var/lib/docker 2/dev/null fi配合 crontab 每小時(shí)執(zhí)行一次或者在開(kāi)發(fā)機(jī)啟動(dòng)時(shí)執(zhí)行能起到預(yù)警作用。Windows 下則可以用計(jì)劃任務(wù) PowerShell 腳本實(shí)現(xiàn)類似效果核心思路一致占用率超過(guò)閾值就輸出提示而不是等到磁盤(pán)寫(xiě)滿才發(fā)現(xiàn)。第四目錄遷移。如果系統(tǒng)盤(pán)本身不大建議把容易膨脹的目錄整體遷移到數(shù)據(jù)盤(pán)。Windows 下可以把 npm 緩存、Docker 數(shù)據(jù)目錄、用戶下載目錄遷移到 D 盤(pán)或外置 SSD。macOS 下可以把~/Library/Caches下的主要緩存目錄改用軟鏈接指向外部磁盤(pán)。遷移操作需要謹(jǐn)慎涉及系統(tǒng)路徑時(shí)先查文檔避免影響已有服務(wù)。10. 常見(jiàn)問(wèn)題與排查方法清理過(guò)程中可能會(huì)遇到一些問(wèn)題下面按現(xiàn)象的維度做一張排查表。問(wèn)題現(xiàn)象可能原因排查方式解決方案刪除 node_modules 后項(xiàng)目跑不起來(lái)缺少鎖文件或依賴版本漂移檢查 package-lock.json 是否存在用鎖文件重新 install或還原備份pnpm store prune 后依賴損壞清理了仍被引用的包檢查 pnpm 的報(bào)錯(cuò)信息重新執(zhí)行 pnpm install 修復(fù)清理 Docker 鏡像后容器無(wú)法啟動(dòng)容器的鏡像被刪除或 tag 丟失docker ps -a 查看容器狀態(tài)重新 docker-compose up 或 pull 鏡像Docker 卷清理后數(shù)據(jù)丟失匿名卷里有數(shù)據(jù)庫(kù)數(shù)據(jù)清理前未執(zhí)行 docker volume ls 確認(rèn)從備份還原或提前掛載命名卷刪除文件后磁盤(pán)空間沒(méi)有釋放文件被進(jìn)程占用尤其 Docker 和日志進(jìn)程lsof L1 查看句柄重啟相關(guān)服務(wù)后再確認(rèn)journalctl 清理后空間仍在漲journald 配置未持久化查看 journald.conf 配置修改配置并重啟服務(wù)npm cache clean 后安裝變慢緩存被清空需重新下載安裝日志顯示從網(wǎng)絡(luò)拉取屬于正常現(xiàn)象可接受WizTree 掃描結(jié)果和系統(tǒng)顯示不一致權(quán)限或掃描模式問(wèn)題以管理員身份運(yùn)行工具重新掃描或?qū)Ρ?df 輸出最值得注意的坑是“文件被占用導(dǎo)致空間不釋放”。在 Linux 下如果一個(gè)文件被進(jìn)程打開(kāi)即使你刪除了它空間也要等進(jìn)程關(guān)閉后才釋放。如果刪完文件發(fā)現(xiàn)磁盤(pán)占用沒(méi)變用下面命令查找被刪除但仍然打開(kāi)的文件lsof L1找到對(duì)應(yīng)的 PID 后重啟對(duì)應(yīng)進(jìn)程即可釋放空間。Windows 環(huán)境下被占用的文件通常會(huì)直接提示“操作無(wú)法完成”需要先關(guān)閉相關(guān)程序或者用 PowerShell 的 handle 工具定位占用進(jìn)程。11. 最佳實(shí)踐與使用建議結(jié)合前面所有清理方案總結(jié)幾條工程化的建議。先做容量規(guī)劃再動(dòng)手清理。不要在沒(méi)有備份的情況下直接執(zhí)行docker system prune -a --volumes或rm -rf node_modules尤其是公司項(xiàng)目或重要數(shù)據(jù)目錄。建議第一次清理時(shí)先做記錄把各目錄清理前的體積寫(xiě)下來(lái)清理后對(duì)比這樣能明確知道每個(gè)方案釋放了多少空間。清理命令從風(fēng)險(xiǎn)低的開(kāi)始。推薦順序是包管理器緩存、構(gòu)建緩存、node_modules、Docker 構(gòu)建緩存、Docker 懸空鏡像、系統(tǒng)日志最后才是 Docker 卷和 git 歷史。每執(zhí)行一步觀察磁盤(pán)狀態(tài)確認(rèn)沒(méi)有副作用再進(jìn)行下一步。模型文件、Docker 卷這類重要資源優(yōu)先考慮遷移而不是刪除。遷移到獨(dú)立磁盤(pán)后既能保留資源又不占系統(tǒng)盤(pán)空間。遷移前務(wù)必備份遷移后驗(yàn)證路徑是否生效。批量任務(wù)或團(tuán)隊(duì)協(xié)作的場(chǎng)景中要把依賴安裝從本地搬到 CI。本地只需要一份最小的運(yùn)行環(huán)境開(kāi)發(fā)驗(yàn)證盡量使用共享緩存。這樣能從根本上減少每個(gè)開(kāi)發(fā)者的磁盤(pán)壓力。最后給開(kāi)發(fā)機(jī)建立一種“每周一次清理”的習(xí)慣。可以不用每周都清理但每周看一次磁盤(pán)使用率發(fā)現(xiàn)增長(zhǎng)趨勢(shì)時(shí)再執(zhí)行對(duì)應(yīng)清理總比磁盤(pán)爆滿后緊急處理省事得多。12. 總結(jié)與下一步FDE 磁盤(pán)爆滿的問(wèn)題本質(zhì)上不是單一原因?qū)е碌亩且蕾嚹夸洝⒕彺妗ocker 資源、系統(tǒng)日志和模型文件長(zhǎng)期累積的結(jié)果。最優(yōu)先要做的事是先跑一遍磁盤(pán)分析工具把最大的三個(gè)目錄找出來(lái)再根據(jù)類型決定清理還是遷移。最容易踩的坑有兩個(gè)一是 Docker 卷清理攜帶數(shù)據(jù)丟失風(fēng)險(xiǎn)二是文件被進(jìn)程占用導(dǎo)致空間沒(méi)有真正釋放。前者靠清理前檢查解決后者靠 lsof 定位進(jìn)程解決。如果你現(xiàn)在磁盤(pán)還夠用建議先寫(xiě)一個(gè)磁盤(pán)告警腳本把閾值設(shè)到 85%然后再?zèng)Q定要不要主動(dòng)清理。如果磁盤(pán)已經(jīng)開(kāi)始報(bào)警按照第二節(jié)到第八節(jié)的順序從緩存和 node_modules 開(kāi)始清最后再處理 Docker 卷和模型文件。整套流程走完磁盤(pán)至少能騰出一片不小的空間也能讓后續(xù)開(kāi)發(fā)環(huán)境保持一個(gè)干凈可控的狀態(tài)。