开发者的 Mac 磁盘为什么越用越满？用 SpacePeek 排查 node_modules、.git、build 和缓存

如果你是一名 Mac 开发者，可能遇到过一个很奇怪的问题：

刚买电脑的时候，硬盘空间怎么看都够。

用了几个月以后：

Macintosh HD
剩余空间：越来越少

打开 Finder 看了一圈，却发现：

“我也没存多少电影啊。”

再仔细看看项目目录：

Projects/
├── project-a/
├── project-b/
├── project-c/
├── old-project/
└── experiments/

每个项目看起来都不算特别大。

但真正展开以后，可能会发现：

node_modules/
.git/
build/
dist/
target/
cache/
backup/

这些目录一个比一个“能吃”。

问题来了：

这些目录到底哪些可以清理？

更准确一点：

为什么一个看起来只有几 GB 的源码项目，最后可能膨胀成几十 GB？

这篇不准备给出一张简单的“删除清单”。

因为开发目录最怕的就是：

看到目录很大 → 直接删。

更稳妥的做法是先找到空间异常的位置，再判断它为什么这么大。

而这正是 SpacePeek 比较适合参与的地方。

SpacePeek 可以从 Finder Quick Look 直接查看文件夹大小、最大项目、Contents 和目录结构，并通过搜索进一步定位文件和文件夹。官方目前采用按需扫描，而不是后台建立全盘索引。(spacepeek.space)

---

一、开发者为什么特别容易遇到“磁盘越用越满”？

普通用户的文件增长通常比较直观：

照片
视频
文档
下载

开发环境则不一样。

一个项目可能同时拥有：

源码
依赖
Git 历史
构建产物
缓存
测试数据
日志
临时文件
备份
压缩包

而且很多目录是工具自动产生的。

你可能甚至不知道它什么时候变大的。

比如：

2026-01
project = 2 GB

2026-04
project = 8 GB

2026-08
project = 31 GB

源码本身可能只增加了几百 MB。

剩下的空间增长，可能来自：

node_modules
.git
build
cache
backup

所以开发者排查磁盘空间时，最重要的第一步不是：

“找垃圾文件。”

而是：

“找出空间增长发生在哪里。”

---

二、先建立一个概念：源码大小 ≠ 项目目录大小

这是开发者非常容易忽略的一点。

例如一个项目：

src/
    200 MB

看起来很小。

但整个项目：

project/
├── src/           200 MB
├── node_modules/    8 GB
├── .git/            3 GB
├── build/           2 GB
├── cache/           5 GB
└── backup/          7 GB

最后：

project ≈ 25 GB

所以如果你只看源码：

“这个项目明明没多少代码。”

完全可能。

因为真正占空间的不是代码。

而是围绕代码工作的整个环境。

---

三、第一嫌疑人：node_modules

如果你使用 Node.js 生态，node_modules 几乎是绕不开的话题。

一个项目：

package.json
package-lock.json
src/
node_modules/

真正让目录膨胀的经常是：

node_modules/

原因也不难理解。

现代 JavaScript 项目的依赖树可能非常复杂：

你的项目
 ↓
依赖 A
 ↓
依赖 B
 ↓
依赖 C
 ↓
更多间接依赖

最终产生大量文件。

而且这些文件不一定是几个大文件。

可能是：

几十万甚至更多的小文件

所以这里有一个很重要的认知：

目录占用空间，不只是“大文件”造成的。

文件数量本身也会带来明显的存储和扫描成本。

---

四、那 node_modules 能不能删？

通常来说：

如果项目可以通过 package.json / lockfile 重新安装依赖，那么 node_modules 往往属于可以重新生成的内容。

但这句话后面有一个非常重要的限定：

“可以重新生成”不等于“任何时候都应该删除”。

比如你正在：

离线开发

或者：

当前项目环境刚好配置完成

这时候删除以后，下一次工作可能需要重新安装依赖。

所以真正的问题不是：

node_modules 能不能删？

而是：

我现在是否愿意用重新安装依赖的时间，换取这部分磁盘空间？

这就是工具无法替你做出的决定。

---

五、SpacePeek 在这里负责什么？

它不需要告诉你：

“删除 node_modules。”

它只需要让你看到：

project/
├── src/             300 MB
├── node_modules/     11 GB
├── build/             2 GB
└── .git/              1 GB

这时候问题已经清晰很多。

你原本只知道：

“Mac 磁盘快满了。”

现在变成：

“原来这个项目的 node_modules 就占了 11 GB。”

这就是空间分析的价值。

SpacePeek 的 Overview 和 Contents 都是围绕这个过程设计的：先看文件夹整体情况，再继续向下浏览具体目录。(spacepeek.space)

---

六、第二嫌疑人：.git

如果 node_modules 是“文件很多”，那么 .git 更容易让人产生另一种误解：

“源码明明没有这么大，为什么 Git 目录这么大？”

因为 .git 保存的是版本控制相关的数据。

一个项目长期开发以后：

v1
↓
v2
↓
v3
↓
v4
↓
大量 commit

历史记录可能逐渐增长。

尤其是某些项目曾经提交过：

• 大型二进制文件；
• 构建产物；
• 数据文件；
• 压缩包；
• 视频；
• 模型文件；

即使后来从工作目录删除，它们也可能继续存在于 Git 历史中。

所以：

.git 很大

本身并不奇怪。

---

七、但 .git 是一个典型的“千万不要凭大小删除”的目录

因为：

rm -rf .git

这种操作的破坏性非常直接。

工作目录可能还在。

但 Git 仓库历史也可能随之消失。

因此，如果你发现：

.git = 8 GB

正确的思路不是：

“8 GB，删。”

而应该是：

为什么这么大？
       ↓
有没有大文件进入历史？
       ↓
是否需要保留完整 Git 历史？
       ↓
是否有远程仓库？
       ↓
是否可以采用 Git 专门的清理方案？

注意这里已经超出了 SpacePeek 的职责范围。

SpacePeek 可以告诉你：

.git 很大。

但如果你需要进一步分析：

Git 历史里到底是谁占空间。

应该使用 Git 自己的分析方法。

这就是工具边界。

---

八、第三嫌疑人：build 和 dist

很多项目都会产生：

build/
dist/
out/
target/

这类目录。

它们通常保存构建后的结果。

例如：

src/
   ↓
编译 / 打包
   ↓
dist/

如果你反复执行：

build

那么构建产物可能不断变化。

有些项目每次都会完整清理。

有些项目则可能保留额外的缓存。

还有些项目会生成大量中间文件。

因此看到：

dist = 6 GB

不能直接得出：

“dist 没用了。”

你需要知道这个项目的构建流程。

---

九、一个非常实用的判断方法：问自己“它能不能重新生成？”

对于开发目录，可以把文件分成两类。

第一类：源数据

例如：

src/
README.md
配置文件
设计源文件
数据库

通常应该谨慎处理。

---

第二类：可再生成产物

例如某些情况下：

build/
dist/
node_modules/
cache/

这些可能可以重新生成。

但注意：

“可能可以重新生成”必须结合具体项目。

不能把所有同名目录一刀切。

---

十、这就是为什么“按大小排序”只是第一步

假设 SpacePeek 显示：

node_modules   12 GB
.git            8 GB
build           7 GB
assets          5 GB
src             1 GB

如果只看大小：

12 GB
8 GB
7 GB
5 GB

但如果按照“是否可以处理”来看：

node_modules → 需要判断
.git         → 高风险
build        → 可能可重建
assets       → 通常谨慎
src          → 通常不要碰

这就是为什么：

空间分析 ≠ 清理决策。

工具给你排序。

人负责理解。

---

十一、第四类经常被忽略：缓存

开发环境里还有大量：

cache/
.caches/
tmp/
logs/

它们往往非常适合拿来做空间排查。

但“缓存”这个词也容易误导。

缓存通常意味着：

数据可以再次生成。

但具体能不能直接删除，仍然取决于产生它的应用。

例如某些开发工具的缓存：

删除
 ↓
下一次启动重新生成

可能只是第一次启动慢一点。

但某些目录虽然名字里带 cache：

cache/

实际可能包含用户没有其他副本的数据。

所以不要建立：

文件夹名字叫 cache → 直接删。

这样的机械规则。

---

十二、SpacePeek 特别适合做“第一轮排查”

比如：

~/Projects/

你发现：

Projects = 180 GB

继续往下：

project-a = 12 GB
project-b = 72 GB
project-c = 16 GB
project-d = 80 GB

那么：

project-b 和 project-d 值得重点检查。

再进入：

project-d/

看到：

node_modules = 20 GB
.git         = 11 GB
build        = 31 GB
src           = 2 GB

这时候你已经获得了非常有价值的信息：

这个项目不是源码太大，而是构建相关目录异常大。

接下来才是进一步调查。

---

十三、如果是 build 很大，应该怎么继续？

例如：

build = 31 GB

下一步不要直接删除。

先问：

这个目录是什么生成的？

可能是：

Xcode
CMake
Gradle
Rust
Android
前端构建工具

不同工具的清理方式不同。

所以正确流程应该是：

SpacePeek
 ↓
发现 build 很大
 ↓
确认项目构建系统
 ↓
查对应工具的清理方式
 ↓
执行清理
 ↓
重新构建验证

这就形成了：

SpacePeek 负责发现问题，专业工具负责解决问题。

---

十四、如果是 .git 很大，也不要直接删除

更合理的流程：

发现 .git 很大
 ↓
判断是否必须保留历史
 ↓
分析 Git 对象
 ↓
定位大对象
 ↓
根据 Git 工作流决定处理方式

如果只是：

“这个项目已经废弃了。”

那整个项目是否还需要保留，才是更大的问题。

也就是说：

.git 很大

可能最终得到的答案不是：

清理 .git。

而是：

整个项目已经不需要了，可以归档到外部存储。

这就是为什么目录分析必须结合上下文。

---

十五、第五类：备份目录

开发者经常会有：

backup/
old/
archive/
release/
snapshot/

这些目录非常容易越积越大。

例如：

project/
├── backup-2024/
├── backup-2025/
├── backup-2026/
└── current/

可能每个版本都有：

10 GB

最后：

backup = 30 GB

这里最容易犯的错误是：

“backup 肯定是旧东西。”

但备份存在的意义就是：

平时可能用不到，出问题时非常重要。

所以处理备份时应该首先确认：

还有没有其他副本？
是否已经上传？
是否需要保留历史版本？
是否有明确的保留周期？

如果这些问题都没有答案：

不要为了释放空间而急着删除。

---

十六、搜索功能在这里也派上用场

假设：

Projects/

里有大量项目。

你可以先搜索：

backup

或者：

node_modules

然后快速找到相关目录。

SpacePeek 当前支持在文件夹树中按文件、文件夹或项目名称进行搜索。(spacepeek.space)

这对于项目很多的人尤其方便。

你不需要：

project-a
project-b
project-c
project-d
project-e
...

一个一个展开。

---

十七、但不要把“搜索 node_modules”理解成“所有 node_modules 都应该删”

搜索的作用只是：

找出来。

例如：

project-a/node_modules
project-b/node_modules
project-c/node_modules
project-d/node_modules

现在你可以进一步问：

• 哪些项目还在维护？
• 哪些已经废弃？
• 哪些依赖安装成本很高？
• 哪些项目需要离线工作？
• 哪些目录可以重新生成？

这时候搜索结果就变成了一个决策清单。

而不是删除命令。

---

十八、一个很实用的开发者清理模型

可以把开发目录里的内容简单分成四层：

第一层：源数据
↓
源码 / 配置 / 数据 / 素材

第二层：版本历史
↓
.git / 历史备份

第三层：可再生成内容
↓
node_modules / build / dist / cache

第四层：临时内容
↓
tmp / logs / 临时导出

越靠近第一层：

越应该谨慎。

越靠近第四层：

越值得优先检查。

但这只是一个判断框架。

不是删除规则。

因为具体项目的目录语义可能完全不同。

---

十九、如果磁盘只剩 20 GB，应该先查哪里？

假设：

Mac 可用空间：20 GB

你的 Projects 已经占：

200 GB

可以这样处理：

第一轮

SpacePeek 查看：

Projects

找出最大的项目。

第二轮

进入项目：

project-a

查看：

node_modules
.git
build
cache
assets

第三轮

搜索：

backup
cache
build
node_modules

第四轮

逐项判断：

可重新生成？
是否有其他副本？
项目还在用吗？
删除后恢复成本多高？

第五轮

再决定：

删除
移动
归档
保留

这种方式比“全盘扫描 → 自动清理”更适合开发环境。

---

二十、还有一个容易被忽略的问题：SSD 空间不是只由项目目录决定

如果你发现：

Projects = 150 GB

当然值得检查。

但如果整个磁盘：

容量 1 TB
可用 10 GB

而你只找到：

Projects = 150 GB
Downloads = 30 GB
Documents = 20 GB

那么不要假设：

“剩下的空间肯定都是垃圾。”

macOS 还有系统数据、应用数据、各种数据库、缓存以及其他存储区域。

因此 SpacePeek 更适合：

从你能够访问和检查的文件夹开始定位问题。

它并不是 macOS Storage 页面或系统级存储管理机制的完全替代品。

这也是工具边界。

---

二十一、实测这篇文章时，建议准备一个真实开发项目

如果你希望这篇文章最终达到更高的 优快云 质量，可以不要只写概念。

最好找一个你自己的真实项目。

例如：

项目目录：
~/Projects/example-project

记录：

项目总大小：
文件数量：
node_modules：
.git：
build：
dist：
cache：
其他大目录：

然后用 SpacePeek 做一次完整检查。

最重要的是：

不要人为删除测试数据以后再说“清理释放了 XX GB”。

应该保留原始状态，先分析，再处理。

这样文章才真正有“实战”价值。

---

二十二、测试结果最好记录成这样的表

目录	大小	初步判断	最终处理
src/		源数据	保留
node_modules/		可重建依赖	根据项目情况处理
.git/		版本历史	谨慎处理
build/		构建产物	根据构建工具判断
dist/		发布产物	根据用途判断
cache/		缓存	确认来源后处理
backup/		备份	确认副本后处理

这张表有一个好处：

把“空间大小”和“处理决定”分开了。

这样不会让读者形成：

大 = 删除

这种危险的条件反射。

---

二十三、如果想把这篇文章写得更专业，可以加入“为什么”

例如不要只写：

node_modules 很大。

继续问：

为什么？

因为依赖树会带来大量文件和间接依赖。

不要只写：

.git 很大。

继续问：

为什么？

因为版本历史可能保存大量对象，尤其是曾经提交过的大文件。

不要只写：

build 很大。

继续问：

为什么？

因为构建系统可能产生中间产物、缓存或多个目标平台的构建结果。

不要只写：

backup 很大。

继续问：

为什么？

因为多个历史版本可能被长期保留。

这种写法比单纯罗列目录更有技术含量。

---

二十四、SpacePeek 在开发场景中的真正价值

如果让我把它在开发环境里的作用压缩成一句话：

它不是告诉开发者“什么能删”，而是帮助开发者快速发现“什么值得检查”。

这两个定位差别非常大。

例如：

Mac 空间不足
      ↓
Projects 很大
      ↓
某个项目异常
      ↓
build 占 31 GB
      ↓
发现构建产物异常
      ↓
再使用对应构建工具解决

SpacePeek 在这里完成的是：

定位

而不是：

自动修复

这其实也是一个比较稳妥的工具边界。

---

二十五、哪些情况下不应该依赖 SpacePeek？

这部分同样重要。

如果你的目标是：

1. 自动清理系统垃圾

SpacePeek 不是专门的系统清理工具。

2. 自动判断哪些文件可以删除

它不是数据价值判断系统。

3. 分析 Git 历史中的大对象

应该使用 Git 自己的分析手段。

4. 清理 Xcode / Android / Docker 等特定工具产生的数据

优先使用这些工具对应的官方清理机制或专门方法。

5. 管理整个团队的开发环境

这已经属于开发基础设施管理问题。

所以：

SpacePeek 是文件系统排查入口，不是开发环境治理平台。

---

二十六、一个比较稳妥的开发者磁盘排查顺序

如果以后自己的 Mac 又出现空间不足，可以直接按照这个顺序：

① 看整体存储情况
        ↓
② 找出最大的用户目录
        ↓
③ SpacePeek 检查目录结构
        ↓
④ 找最大的项目
        ↓
⑤ 查看 node_modules / .git / build / cache / backup
        ↓
⑥ 搜索重复或历史目录
        ↓
⑦ 判断是否可以重新生成
        ↓
⑧ 确认是否存在其他副本
        ↓
⑨ 再决定删除 / 移动 / 归档
        ↓
⑩ 最后验证释放了多少空间

这个流程最大的特点就是：

把“发现”和“删除”分开。

对于开发环境来说，这一点尤其重要。

---

二十七、写在最后：开发者真正需要的，可能不是“清理神器”

Mac 磁盘空间不足的时候，人很容易陷入一个误区：

“我需要一个能帮我自动清垃圾的工具。”

但很多时候真正缺少的其实是：

我不知道空间到底去哪了。

尤其是开发环境。

因为：

node_modules
.git
build
dist
cache
backup

每一个都可能很大。

但每一个的处理方式又不一样。

所以一个更可靠的思路是：

先找到
   ↓
再理解
   ↓
再判断
   ↓
最后处理

SpacePeek 更适合处在前三步。

它可以从 Finder Quick Look 开始，让你快速看到文件夹大小、最大项目和目录结构，再通过搜索、预览和 Archive Preview 继续缩小范围。官方当前版本为 2.1，支持 macOS 14.0 及以上。(spacepeek.space)

如果你是开发者，我觉得这反而是一个值得保留的使用习惯：

看到磁盘空间不足，先别急着删。

先问三个问题：

谁占空间？

为什么这么大？

它还能不能删？

第一个问题，可以交给工具。

后面两个问题，最好还是留给自己。

因为代码可以重新安装，构建可以重新生成。

但误删的数据，未必能重新生成。