你的硬盘正在被Python吃空：一个清理实战

打开终端，输入du -sh ~，然后盯着那个数字发呆——这是每个Python开发者都经历过的瞬间。你明明没存什么大文件，硬盘却莫名其妙满了。罪魁祸首？那些你早就忘了的虚拟环境。

沉默的存储杀手

Python虚拟环境的设计初衷是隔离依赖，但它有个副作用：疯狂繁殖。一个测试项目、一场黑客松的仓库、跟着教程克隆的代码、临时分支的概念验证——每个都自带一个.venv/文件夹。

更麻烦的是，这些环境不会自己消失。它们像数字蟑螂一样藏在各个角落，等你发现时已经占用了几十GB。

原文给了一个很真实的场景："几个月后，很容易积累几十个环境，消耗数GB空间——而你只在安装失败或硬盘归零时才会注意到。"

这不仅是空间问题。当磁盘接近满载时，系统交换性能暴跌，IDE索引卡顿，甚至编译都会失败。你以为是电脑老了，其实是被自己的实验遗迹埋住了。

垃圾都藏在哪里

很多人以为删掉.venv/就干净了，太天真。

完整的垃圾清单包括：

• .venv/：最显眼的，但只是冰山一角
• Poetry的缓存环境：藏在用户目录深处
• conda环境：可能散落在多个前缀路径.tox/文件夹：测试矩阵的残留
• 散落的__pycache__：每个Python文件都贡献一点
• dist/和build/：打包产物的堆积

原文的关键判断是："这套东西安静增长，因为几乎没有默认工作流会自动清理它。"

这不是用户的错。Python工具链的设计哲学是"显式优于隐式"，但代价就是——你得自己当清洁工。

四步专业清理法

原文提供了一个可复现的工作流，核心原则是"先盘点，再动手"。

第一步：盘点优先

Visibility first, action second.（先可见，后行动。）

别急着删。先用工具扫描，搞清楚：有哪些环境？在哪？多大？多久没用过？

这一步的心理价值被低估了。很多人不敢清理是因为害怕删错，而清单能消除这种焦虑。

第二步：按类型和年龄分类

删昨天的环境和删180天没碰的环境，风险完全不同。原文建议建立简单的分级：

• 缓存和构建产物：几乎零风险，优先处理
• 旧环境（90天+）：低风险，次优先
• 近期环境：需要人工确认

第三步：安全批次清理

从低风险开始。缓存不会破坏项目，环境会。原文的递进策略是：先缓存和产物，再旧环境。

每次操作后用--dry-run模拟，确认影响范围。

第四步：自动化维护

原文的警告很直接："If you do not automate it, the problem returns."（如果你不自动化，问题会回来。）

一次性清理是止痛片，自动化才是疫苗。

KillPy：一个务实的工具

原文提到了KillPy，但特意注明"without turning this into an ad"（不变成广告）。这种克制值得尊重，我们也保持同样距离。

KillPy的定位是"盘点后的执行层"。它能扫描路径、按年龄/大小排序、模拟删除。三个典型用法：

killpy stats --path ~ —— 看整体占用
killpy list --older-than 120 —— 列出120天前的环境
killpy delete --type cache --dry-run —— 模拟删缓存

原文的建议是："For most developers, a monthly pass is enough to keep local environments healthy."（对大多数开发者，每月一次就够了。）

这个频率很合理——不会变成负担，又能防止堆积。

四个常见翻车现场

原文列出的错误清单，每条都是血泪教训：

1. 没盘点就删除

你以为删的是旧环境，其实是正在跑的生产依赖。盘点不是 bureaucracy，是保险。

2. 不看最后访问时间就删

mtime会骗人。一个环境可能一年前创建，但昨天还在用。检查atime或手动确认。

3. 项目运行时清缓存

Poetry、pip、conda的缓存可能被正在进行的安装占用。清理时中断它们，会导致奇怪的半完成状态。

4. 没版本控制锁文件就删环境

这是最痛的。你以为能重建，但pyproject.toml里的版本约束太松，装出来的是完全不同的依赖树。锁文件（poetry.lock、uv.lock等）是重建的保险单。

预防比清理更重要

原文花了相当篇幅讲预防，这才是工程师思维——不重复解决同一个问题。

项目级标准

• 统一用.venv放在仓库根目录
• 文档化官方命令（README里写清楚怎么创建环境）
• 禁止在仓库外创建临时环境

这条规则的价值在于可预测性。当你知道所有环境都在项目根目录，盘点和清理都变成脚本能做的事。

依赖管理可重现

• 保持pyproject.toml健康
• 依赖变更时更新锁文件

原文没展开"健康"的定义，但结合上下文，指的是版本约束要明确，不要用开放的*或宽松的>=。

CI/CD黄金法则

原文给了一个"robust example"（健壮示例）：

python -m venv .venv
.venv/bin/python -m pip install -e ".[dev]"
.venv/bin/python -m pytest

背后的三条原则：

• 每次从零构建环境（不继承残留）
• 不用之前作业的残留状态
• 命令显式、可审计

这看起来慢，但避免了"在我机器上能跑"的幽灵。

15分钟月度剧本

原文提供了一个可落地的维护节奏：

1. 按环境类型审查存储大小
2. 移除缓存和构建产物
3. 审查90天以上未用的环境
4. 确认活跃项目能从锁文件干净重建

原文的承诺是："Follow this playbook and you reduce maintenance friction dramatically."（照这个剧本做，维护摩擦会大幅降低。）

这里的"friction"很准确——不是灾难性故障，而是那种每次装包都慢、每次切换项目都乱的慢性消耗。

最后一点洞察

原文的结尾被截断了，但前面已经足够完整。我们可以补全它的意图：

掌握Python虚拟环境的真正标志，不是你能创建多少，而是你能多轻松地销毁和重建它们。可丢弃性（disposability）是基础设施成熟度的指标。

当你能在15分钟内清理完所有环境，又能在5分钟内重建任何项目——这时候你才真的"拥有"了你的开发环境，而不是被它拥有。

现在，去跑那个du命令吧。我赌你会惊讶。