Mac 开发者缓存怎么清：npm、uv、Go、Playwright 与工具缓存的分层指南

缓存清理的原则是先识别所有者

“缓存”这个词包含了几种不同的东西：可以从网络重新下载的压缩包、从源代码重新生成的编译产物、为了加速启动而保存的浏览器运行时、工具自己维护的索引，以及看起来像缓存但实际上包含模型、数据库或登录状态的持久数据。删除前要知道是谁创建它、哪个项目正在使用它、恢复是否依赖网络、是否能接受恢复时间。

示例电脑的用户缓存总量不小，但清理各部分的收益并不一样。~/.npm 约 4.7 GB，其中 _cacache 约 2.7 GB、_npx 约 2.0 GB；~/.cache 约 3.8 GB，其中 uv 约 1.8 GB、开发工具运行时约 1.6 GB；~/Library/Caches 约 9.1 GB，其中 ms-playwright 约 2.8 GB、开发工具缓存约 1.8 GB、go-build 约 1.1 GB、Google 约 1.0 GB。这些数据能帮你排出优先级，但并不意味着每个目录都该删。

先用 du -sh 只做测量，再用工具自己的 info、verify、dir 或 list 命令确认内容。清理后先运行一个有代表性的任务，例如 npm install、uv sync、go test 或 Playwright 启动，观察缓存是否按预期重建。把“空间回收”和“工作流恢复”都记下来，才能知道清理动作是否值得。

1. 关闭 npm install、uv、Go 构建、Playwright、Homebrew 和任何会继续写缓存的任务。
2. 记录 df -h /，再记录 ~/.npm、~/.cache、~/Library/Caches 和项目 node_modules 的大小。
3. 选择一个具体工具，先执行它的验证或预览命令，再清理对应的最小范围。
4. 重新运行一个真实开发任务，确认依赖、测试和本地开发服务器仍能启动。
5. 设置维护周期与缓存预算，避免把紧急清理变成每次构建前的固定动作。

缓存清理会把时间成本从过去的下载或编译转移到下一次使用。空间确实紧张时值得做，但不应在没有故障或预算压力时反复执行。

npm：先 verify，再决定是否清空

npm 的缓存通常由内容寻址的包数据和临时 npx 环境组成。npm cache verify 可以检查缓存索引和内容，适合在怀疑缓存损坏时、或决定是否清理之前运行。若只是为了回收空间，npm cache clean --force 会删除缓存并让后续安装重新下载；它不会替你删除项目中的 node_modules，也不会修改 package.json 或 lockfile。

示例电脑的 ~/.npm 约 4.7 GB，其中 _cacache 约 2.7 GB，_npx 约 2.0 GB。_cacache 对多个项目复用同一份包很有价值，_npx 则可能积累一次性 CLI 的环境。可以先查看目录修改时间和最近使用的命令，再决定是否清理全部，或只处理长时间没有使用的临时环境。频繁切换 Node 版本、运行自动化脚本和使用多个 npm registry 都会让缓存增长更快。

不要把 node_modules 当成 npm cache。node_modules 属于某个项目，可能包含本地补丁、原生模块构建结果和未提交的调试文件。删除前确认 lockfile 在版本控制中、当前分支可以重新安装、私有 registry 凭证仍有效。若项目是离线构建或使用内部包，清空全局缓存的风险高于普通公开依赖。

清理后使用项目原来的 npm ci 或 npm install，而不是顺便升级 npm 或修改依赖范围。若第一次安装失败，先区分网络、权限、Node ABI 和 registry 问题；不要因为下载失败就反复清空缓存。清缓存修不好写错的 package.json，也修不好失效的认证配置。

uv、pip 与 Python 缓存：不要误删虚拟环境

示例电脑的 ~/.cache/uv 约 1.8 GB，属于 Python 依赖下载和构建复用的一部分。uv cache dir 可以告诉你当前工具实际使用的缓存位置，uv cache clean 会清理 uv 管理的缓存；如果团队使用 pip，则应通过 pip cache dir、pip cache info 和 pip cache purge 处理对应范围。uv 和 pip 各自维护自己的缓存，清理其中一个不会清掉另一个；执行前先确认命令和路径。

虚拟环境通常位于项目目录、用户目录或工具管理的专用位置，它包含解释器、已安装包和项目运行时状态。它不是全局下载缓存。删除 ~/.cache/uv 不等于删除 .venv，但删除项目目录中的 .venv 会让本地开发、脚本和编辑器解释器设置失效。空间告急时，优先找出长期未使用项目的虚拟环境，再决定是否可以用锁文件重建。

如果依赖包来自私有索引或本地 wheel，清理前确认网络、凭证和仓库可用。缓存命中可以让离线调试继续，清空后第一轮安装可能需要重新编译科学计算包或原生扩展。对于 CI，缓存键应包含 Python 版本、平台和锁文件哈希，否则一次清理后可能反复下载不兼容的 wheel 包。

清理后运行一个项目的测试或启动命令，而不是只运行 pip list。列表可以读取残留元数据，不能证明二进制扩展、环境变量和本地服务都能工作。验证真实工作流，才能把空间回收与可用性联系起来。

Go 与 Rust：构建缓存可以删，模块下载要看恢复成本

示例电脑的 ~/Library/Caches/go-build 约 1.1 GB。Go 的构建缓存可以由 go clean -cache 清理并在后续构建中重建；模块下载缓存通常位于 GOPATH 下的 pkg/mod，删除它会让多个项目重新下载依赖；它的文件默认是只读的，要清理请用 go clean -modcache，不要直接 rm。两者都不是源代码，但恢复所需的时间不同，不要为了清理 build cache 顺手删掉模块下载缓存。

先运行 go env GOCACHE、go env GOMODCACHE 了解实际路径，再测量每一项。对只在旧分支使用的模块，确认仓库可以访问、代理配置未失效后再清理。对于需要离线编译的工作机，保留常用模块缓存往往比节省几个 GB 更有价值。Go 的构建缓存增长到一定程度时可以定期清理，但应在构建间隔或低峰期执行。

Rust 的 target 目录和 Cargo registry、git checkout 也要分开理解。target 通常可以按仓库清理，cargo clean 只影响当前包的构建产物；全局 registry 和 git checkout 可能被多个仓库复用。若项目使用 workspace、跨平台 target 或大型原生依赖，先测量最大的仓库，再删除最久不用的 target，而不是清空整个 Cargo 目录。

构建缓存清理后的第一次编译会变慢，依赖缓存清理后的第一次构建还会增加网络时间。把这两个成本分别记录，下一次就能针对真正膨胀的类别维护。如果构建仍然失败，清缓存也代替不了检查 go.mod、Cargo.lock、工具链版本和编译器报错。

Playwright、浏览器和 pnpm：下载型缓存要设预算

示例电脑的 ~/Library/Caches/ms-playwright 约 2.8 GB，说明浏览器运行时很可能比普通 npm 包更占空间。Playwright 的浏览器是测试运行时，不是项目源码；可以通过当前项目使用的 Playwright 命令查看已安装浏览器，并在确认团队仍能重新安装的情况下卸载不再需要的版本。不要在测试运行时删除浏览器目录，否则正在执行的测试会因为找不到浏览器而失败。

pnpm store 可能位于用户缓存或专用存储路径，先运行 pnpm store path 确认位置，再用 pnpm store prune 清理没有被任何项目引用的包。它和删除 node_modules 的区别在于：store 是跨项目的内容寻址仓库，prune 会影响未来安装命中率，但不会主动修改项目 manifest。清理后第一次安装可能重新链接或下载大量包。

~/Library/Caches 里还有浏览器自身的缓存和各种工具的下载缓存；Next.js 等前端框架的编译缓存则通常在项目里的 .next 等目录。对单个应用，优先使用它自己的清理入口；对站点构建，先删除已停止维护的项目的 .next 或 build 输出。不要用“清理 Chrome”来解决 Playwright 运行时问题，也不要把浏览器用户配置、书签或登录数据当作测试缓存。

在团队和 CI 中设置缓存预算比在个人电脑上频繁手删更稳定。短生命周期的 CI Runner 可以不保留浏览器缓存，持久 Runner 则按 Playwright 版本和锁文件建立键，并在达到预算时淘汰旧版本。开发机保留当前主线测试所需的一套运行时，历史版本需要时再安装，通常是速度与磁盘之间更好的平衡。

Homebrew、Docker、模型和工具运行时要特别谨慎

Homebrew 的清理可以先用 brew cleanup -n 预览，确认后再执行 brew cleanup。它会移除过时的下载文件和已安装 formula 的旧版本；不指定软件包、全局运行时，只要没有设置 HOMEBREW_NO_AUTOREMOVE，它还会卸载已经没有任何软件需要的依赖（预览输出里列在“Would autoremove”下）。正在使用的版本、tap 配置和已安装的程序属于另一类内容。不要在磁盘告急时删除 /opt/homebrew 或 /usr/local 下的整个目录；Homebrew 管理的文件，交给 brew 自己处理。

Docker Desktop 把镜像、构建缓存、已停止的容器和命名 volume 都放在 Linux 虚拟磁盘中。docker system df 可以先显示构成，docker builder prune、docker image prune 和 docker volume prune 的影响范围各不相同。volume 里可能是数据库唯一副本，不能因为它“未被当前容器使用”就把它当普通缓存。清理 Docker 前先导出必要数据并确认 compose 文件能重建服务。

Hugging Face 和 Ollama 的模型文件通常不是普通缓存，它们可能是数 GB 到几十 GB 的持久资产。模型可以重新下载，但需要时间、网络和磁盘临时空间；删除前确认模型名称、量化版本和本地服务依赖。开发工具目录下的运行时文件也可能服务当前工作流，先确认版本和恢复渠道再处理。

大型工具清理的共同原则是先看工具提供的列表、大小和 prune 命令，再按对象删除。不要为了清理几 GB 把整个应用的 group container、虚拟磁盘或模型目录递归删除。工具自己知道哪些层可重建，人工只需要确认哪些数据值得保留。

用户缓存目录不要整体递归删除

~/Library/Caches 约 9.1 GB，看起来像最快的目标，但其中包含 Google、开发工具、Playwright、Go、pnpm、Homebrew、Sparkle 和多个应用自己的缓存。它们的恢复行为、登录依赖和文件锁都不同。退出对应应用、按子目录检查、处理一个类别并重新打开应用，是比一次性清空更可靠的顺序。

对用户缓存而言，删除前最好保留一份路径清单，记录哪些目录由什么应用创建。某些应用会把下载队列、索引或数据库放在 Caches 旁边，某些应用在运行时会立即重新创建目录。若应用开启了同步或自动更新，清理后它可能马上重新下载，造成“空间没有变”的错觉；重新测量增长来源比再次删除更重要。

示例电脑的 ~/.cache 中有约 1.6 GB 开发工具运行时和约 1.8 GB uv；这些目录不是同一个工具，也不能以名称相近为理由合并处理。清理前查看工具版本、最近使用时间和安装方式，确认恢复命令可以在空间紧张的情况下完成。第一次重新下载可能需要额外临时空间，所以不要把磁盘清到只剩几百 MB。

当可用空间少于 5 GB 时，先从已经验证可再生的单一缓存类别释放几 GB，再做其他工作。空间恢复后，为每个工具设定预算和维护周期，避免让系统每次都在低空间边缘运行。

建立适合开发机的缓存预算

缓存没有“越少越好”的目标。活跃项目需要依赖和构建复用，完全清空会把时间成本转移到每次安装和构建。可以给 npm、pnpm、uv、Go、Playwright 和 Homebrew 分别设定提醒阈值，例如达到 2 GB、5 GB 或团队规定的上限后先预览，再选择最旧或最少使用的对象。阈值应基于你的编译峰值、网络速度和离线需求调整。

每周记录一次主要目录的大小变化，每月检查一遍不再维护的仓库和工具版本。项目停止使用时，优先删除它的 node_modules、.venv、target、.build 或 .next；全局缓存仍能服务其他项目就先保留。把锁文件和恢复命令放在仓库里，把缓存清理记录放在维护文档里，下一次不用重新猜测。

AskClean 可以把开发者缓存、Xcode 产物、项目构建目录和大型未知文件夹并列展示，帮助你看清空间到底被谁占用；你确认的清理项会被永久删除，不会移到废纸篓。它不应替代 npm、uv、Go、Docker 或 Playwright 的官方清理命令，也不应把模型、volume、dSYM 和源代码藏在一个删除按钮后面。清晰的分类和恢复说明，才是开发机清理中最有价值的部分。

示例电脑开发者缓存实测

数据来自 2026-10-31 的只读目录检查，用于决定先处理哪些类别。

缓存大小不是固定指标，清理操作和工具运行都会随时改变它们；动手之前请重新测量。

常见问题