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