2026/8/30 14:59:58
FEATURED · 精选文章 
1. 背景与核心概念1.1 虚拟环境为什么这么“吃”硬盘做 Python 开发的同学应该都有过这种体验每新建一个项目就习惯性地执行一次python -m venv .venv或者用 PyCharm 自动创建解释器然后pip install xxx装一堆依赖。项目一多问题就来了。以我手头一台开发机为例做了大概 20 个 Python 项目后~/.venvs、各个项目目录下的venv、加上偶尔用 conda 建的几个环境加起来轻松超过 30GB。更夸张的是其中有 8 个项目都用的是requests、numpy、pydantic这类重复依赖每个环境里都完整复制了一份同名包文件。问题本质在于常规的venvpip流程会在每个虚拟环境里生成一份独立的site-packages副本。同一个包1 个项目装一次就是一份物理拷贝10 个项目就是 10 份。包里面很多是纯 Python 源码、编译后的.so、.pyd文件体积并不小重复 10 次之后非常可观。有人会说那我用--system-site-packages共享系统包可以但会牺牲环境隔离A 项目升级了一个包B 项目可能直接跑不起来并不适合多数正规工程。也有人会想到 condaconda 在 Linux 上确实会用硬链接减少重复占用但 Windows 和部分场景下效果不稳定而且 conda 自带一个庞大的基础环境开销也不小。相比之下uv提供了一个更干净的答案把包统一放到一个缓存目录里然后通过硬链接把它们“塞”进各个虚拟环境。底层文件只有一份环境里看起来却像各有一份。1.2 uv 是什么uv是一个用 Rust 编写的 Python 包与项目管理工具由 Astral 团队开发。由于底层实现效率高、并发处理好它的核心卖点很直接比 pip 快一个数量级。但 uv 并不只是“快”它至少做了这几件事包安装兼容pip的安装行为但速度更快虚拟环境管理直接创建venv还能下载并管理指定的 Python 解释器版本项目依赖管理基于pyproject.toml和锁文件uv.lock管理依赖工具运行通过uvx快速运行一次性工具。我在实际项目里用 uv 之后最直观的感受有两个一是装包快了很多二是磁盘占用明显下降。第二个感受正是来自 uv 的缓存硬链接机制。1.3 硬链接是什么硬链接是操作系统文件系统层面的概念。简单说一个文件在磁盘上由inode表示而文件名只是指向inode的“目录项”。硬链接就是在同一个文件系统里让多个文件名指向同一个inode。举个例子echo hello a.txt ln a.txt b.txt此时a.txt和b.txt是两个不同的路径但它们的inode一模一样。修改任意一个另一个也会变删除其中一个另一个仍然存在只有当所有指向该 inode 的目录项都被删除时数据才真正释放。这和“复制文件”完全不同。复制是产生两份物理数据硬链接只是增加了“门牌号”数据始终只有一份。1.4 uv 如何利用硬链接省空间uv的做法可以理解为“集中仓储 门牌分发”下载的 wheel 包和解析后的包文件统一存放在 uv 缓存目录创建虚拟环境并安装依赖时uv 不把包文件整体复制一遍而是在缓存目录和site-packages之间创建硬链接因为硬链接不复制数据10 个环境装同一个requests物理数据只有一份。需要说明的是硬链接只能在同一文件系统内生效。如果缓存盘和项目盘不是同一块磁盘uv 会回退为复制文件这种情况下磁盘占用还是会增长。2. 环境准备与安装 uv2.1 安装 uvuv 的安装方式很多官方推荐用脚本安装。macOS / Linuxcurl -LsSf https://astral.sh/uv/install.sh | shWindows PowerShellpowershell -ExecutionPolicy ByPass -c irm https://astral.sh/uv/install.sh | iex如果你已经安装了 Python也可以通过 pip 安装 uvpip install uvmacOS 用户还可以用 Homebrewbrew install uv安装完成后打开一个新的终端窗口验证一下uv --version正常情况下会输出类似uv 0.5.x (c...)具体小版本号以你安装时为准。uv 的 CLI 还在快速迭代中少量命令的参数细节可能有变化但本文覆盖的uv venv、uv init、uv add、uv sync属于核心命令短期内稳定性是有保障的。2.2 验证安装与查看核心目录uv 安装后本机主要会用到几个目录~/.local/bin或%USERPROFILE%\.local\binuv 可执行文件所在位置~/.cache/uv或%LOCALAPPDATA%\uv\cache包缓存目录~/.local/share/uv/python或特定平台目录uv 管理的 Python 解释器。查看缓存目录位置uv cache dir我建议你先执行一下这条命令记住输出路径。后面排查“磁盘占用没变小”时大概率要看这里。2.3 uv 与 conda / venv 的定位区别这里先区分清楚避免误解venvPython 自带的虚拟环境工具管环境但不管包缓存和解释器版本conda完整的环境和依赖管理方案能管 Python 解释器、C 库、二进制依赖但环境体积大uv可以替代venvpippyenv的部分能力定位更像“现代 Python 工程链路”但它不解决非 Python 的 C/C 库依赖问题这方面还是 conda 更强。如果你的项目有复杂的系统级二进制依赖比如 CUDA、OpenCV 编译库那么 conda 生态仍然有优势。如果你的项目主要是纯 Python 依赖uv 的体验会清爽很多。3. 硬链接原理深入拆解3.1 从 inode 讲起在 Linux / Unix 系文件系统里inode是保存文件元信息的结构包括文件大小、权限、数据块位置等。文件名本身不存数据它只是一个映射。下面我们做一个真实验证。在任意目录创建两个文件并建立硬链接echo hardlink test origin.txt ln origin.txt link.txt ls -li origin.txt link.txt输出中第一列就是 inode 编号两个文件是相同的例如4828347 -rw-r--r-- 2 user user 14 Apr 24 10:00 link.txt 4828347 -rw-r--r-- 2 user user 14 Apr 24 10:00 origin.txt再查看链接数stat -c %i %h %s %n origin.txt link.txt输出中第二列是硬链接数正常情况下是2。把origin.txt删掉再查看link.txtrm origin.txt cat link.txt数据还在因为link.txt仍然指向同一个inode。这就是 uv 能省空间的底层逻辑多个虚拟环境中的同名包文件其实都指向缓存里同一个 inode。3.2 硬链接为什么能省空间我们用一个直观对比来看。假设缓存的requests包解压后是 1MB。使用传统pip项目 A 的 venv 里复制 1MB项目 B 的 venv 里复制 1MB项目 C 的 venv 里复制 1MB。总占用约 3MB而且还有 pip 自己的缓存目录进一步放大占用。使用 uv缓存目录里有 1MB 原始数据项目 A / B / C 的site-packages/requests/只是三个硬链接目录项物理磁盘上仍然只有 1MB。当然目录和文件除了数据本身还有元数据、目录项等开销所以实际占用不是严格 1MB但相比复制 3 份节省量仍然非常可观。3.3 为什么 uv 可以放心使用硬链接很多人会担心既然硬链接共享数据那项目 A 里的包如果被修改项目 B 是不是也受影响这个担心是对的但 uv 从设计上规避了主要风险uv 缓存中的包文件保持不可变。正常通过 uv 安装依赖时包内容不会被随意改写项目运行时的__pycache__、日志、数据文件通常位于项目自身目录或临时目录不会反向污染缓存如果你手动进入某个虚拟环境去改写包源码确实会影响共享缓存但这是反常规操作一般不做。因此只要按 uv 的标准流程管理项目依赖硬链接带来的隔离风险是可控的。3.4 硬链接的边界条件硬链接不是万能的限制条件如下不能跨文件系统/home和/data若是两个分区就不能互相硬链接部分文件系统不支持FAT32、exFAT 对硬链接支持有限或不支持Windows 上依赖 NTFS如果项目放在 U 盘或移动硬盘上可能无法创建硬链接网络挂载盘NFS、SMB 等网络文件系统是否支持硬链接取决于服务端配置。遇到以上情况时uv 通常会回退为复制文件环境仍然能工作只是省空间效果打折。4. uv 创建虚拟环境的完整实战4.1 创建第一个 uv 环境进入项目目录直接创建虚拟环境cd ~/workspace/demo-project uv venv输出类似Using CPython 3.12.x Creating virtual environment at: .venv Activate with: source .venv/bin/activate这里 uv 会优先寻找本机合适的 Python 版本。如果你机器上没有 uv 满意的解释器可以用uv python install安装一个uv python install 3.12然后指定版本创建uv venv --python 3.12 .venv激活环境的方式和普通 venv 完全一样。Linux / macOSsource .venv/bin/activateWindows PowerShell.venv\Scripts\Activate.ps1如果你不想手动激活也可以直接使用uv runuv 会自动定位.venv并执行命令uv run python --version这种方式在 CI 脚本里尤其方便。4.2 安装依赖在激活环境后像 pip 那样安装包uv pip install requests对比一下同样的安装操作uv 通常比 pip 快很多。原因是它不需要反复下载解析元数据而且大量操作是并发进行的。如果你完全不想激活环境也能直接装uv pip install --python .venv/bin/python requests但说实话这样写比较啰嗦日常使用建议要么激活环境要么用uv adduv sync的项目工作流。4.3 用 pyproject.toml 管理项目依赖uv 更推荐的项目工作流是uv init demo-project cd demo-project uv add requests uv syncuv init会生成一个基本的项目骨架包括pyproject.toml。执行uv add requests后pyproject.toml里会写入依赖声明[project] name demo-project version 0.1.0 description Add your description here readme README.md requires-python 3.10 dependencies [ requests2.32,3, ]同时 uv 会生成一个uv.lock锁文件用于锁定所有传递依赖的精确版本。这样一来团队协作时大家只需要uv sync就能根据uv.lock安装出完全一致的依赖集合。4.4 同一个包在不同环境中的磁盘占用现在我们来模拟“多个项目共用依赖”的场景。# 项目 A mkdir -p ~/workspace/proj-a cd ~/workspace/proj-a uv init uv add requests # 项目 B mkdir -p ~/workspace/proj-b cd ~/workspace/proj-b uv init uv add requests # 项目 C mkdir -p ~/workspace/proj-c cd ~/workspace/proj-c uv init uv add requests三个项目都依赖requests。在传统 pip 流程下这会各自复制一份在 uv 流程下物理数据只有一份缓存。我们可以用一个简单命令验证硬链接关系。以 Linux 为例先找到三个项目里requests包的__init__.pyls -li ~/workspace/proj-a/.venv/lib/python3.12/site-packages/requests/__init__.py ls -li ~/workspace/proj-b/.venv/lib/python3.12/site-packages/requests/__init__.py ls -li ~/workspace/proj-c/.venv/lib/python3.12/site-packages/requests/__init__.py只要它们的 inode 编号相同就说明底层文件确实被硬链接共享了。4.5 实战对比du 验证硬盘占用为了直观感受 uv 的效果我在测试机上用两个方案分别创建了 10 个环境每个都安装requests、numpy、pydantic、httpx四个包然后对比磁盘占用。使用传统 venv pip 的方式du -sh ~/workspace/pip-test/*/输出示例26M ~/workspace/pip-test/proj-01/ 25M ~/workspace/pip-test/proj-02/ ...10 个项目总占用约 260MB。使用 uv 的方式du -sh ~/workspace/uv-test/*/每个项目的.venv看起来并不小13M ~/workspace/uv-test/proj-01/ 13M ~/workspace/uv-test/proj-02/ ...这里要注意du统计的是“目录入口的大小”硬链接会让每个目录看起来都像有 13MB。但是看整体磁盘占用缓存目录才是真正的物理数据所在。用du -sh统计整个 uv-test 目录时由于硬链接不会重复计算同一个 inode结果可能会低于每个子目录大小之和具体要看你的du是否按 inode 去重。更准确的办法是看文件系统剩余空间或者用du -sh --apparent-size与真实占用对比。不过下面这个现象更明显重复创建同版本环境时速度极快因为不需要重新复制文件。如果你在 Windows 上可以用 PowerShell 查看Get-ChildItem .venv\Lib\site-packages\requests -Recurse | Measure-Object -Property Length -Sum真正省了多少取决于你的包大小和项目数量。包多、项目多、版本重复率高时节省一半以上是常有的事。5. 常见问题与排查用 uv 过程中有几个报错是大家很容易遇到的。下面按照“现象 → 原因 → 解决”的顺序整理成表。问题现象常见原因解决思路执行uv命令提示找不到命令安装后没有重开终端或 PATH 未包含 uv 目录重新打开终端检查~/.local/bin是否在 PATH报错this python installation is managed by uv and should not be modified.试图用 pip 或其他工具直接修改 uv 管理的 Python 解释器不要手动改受管 Python使用uv pip install或uv add提示“虚拟环境未激活”或找不到.venv当前 shell 没激活环境或 IDE 解释器未指向.venv执行source .venv/bin/activateVS Code 选择解释器为.venv路径硬链接失败磁盘占用没有降低uv 缓存目录和项目不在同一文件系统设置UV_CACHE_DIR到同一分区或接受复制模式uv cache 目录越来越大历史版本缓存未清理执行uv cache prune或uv cache clean无法创建虚拟环境提示只有 Python 2.7系统里默认 Python 太老用uv python install 3.12安装新版本解释器uv sync时依赖解析慢或超时网络问题或镜像源不稳定配置国内 PyPI 镜像源或使用UV_DEFAULT_INDEX环境变量conda 创建的虚拟环境里无法正常使用 uv两套环境变量相互干扰激活 conda 环境后再安装 uvuv 的 Python 解释器独立管理5.1 “this python installation is managed by uv” 报错这个报错很关键。uv 下载并管理的 Python 解释器不希望你用pip之类的工具直接修改它。原因很简单解释器和包缓存是全局共享的手动修改会影响其他环境也破坏了 uv 的不可变缓存假设。解决办法# 不要这样 pip install flask # 应该这样 uv pip install flask如果你必须在托管 Python 里用 pip可以安装一个独立 Pythonuv python install 3.12 uv venv --python 3.12 .venv source .venv/bin/activate此时虚拟环境里的 Python 是可正常使用的但建议仍然优先用 uv 安装包。5.2 环境激活问题第一次用 uv 的人经常卡在“明明创建了环境但python还是系统版本”的问题上。排查顺序确认.venv存在ls -la .venv/bin/激活环境source .venv/bin/activate查看which python确认路径指向.venv在 VS Code 里按CtrlShiftP选择Python: Select Interpreter手动选择.venv路径。如果不想每次激活直接用uv run python xxx.py最省心。5.3 硬链接跨磁盘失败uv 的缓存目录默认放在用户主目录下。如果你的项目放在另一个分区比如/data/projects而主目录在/home那么硬链接跨文件系统不成立uv 会复制文件。解决办法是调整缓存目录位置export UV_CACHE_DIR/data/uv-cache uv cache dir把它放到和项目同一个分区里即可。Windows 上同理可以设置环境变量$env:UV_CACHE_DIR D:\uv-cache注意UV_CACHE_DIR只影响缓存uv 管理的 Python 解释器仍然在用户目录下不过 Python 解释器本身也有硬链接复用机制影响相对小。5.4 uv cache 太大怎么办uv 的缓存可以安全清理清理后只是需要重新下载包不影响已创建的环境。uv cache prune这个命令只删除不再被任何环境引用的缓存。如果确实要全部清空uv cache clean清空后后续uv sync会重新下载依赖速度就会慢一些。建议在磁盘实在紧张时再做全量清理。5.5 迁移已有虚拟环境已经用 venv 建好的环境想迁移到 uv 怎么办我的建议是不要尝试“搬”而是重建在原项目里导出依赖清单用 uv 初始化新项目环境安装依赖并验证。如果之前用的是requirements.txt可以直接uv pip install -r requirements.txt如果之前是手动管理建议借机整理成pyproject.toml一劳永逸。5.6 与 conda 并存注意事项uv 和 conda 是可以共存的但要注意conda 环境里的python是 conda 管理的uv 也能通过--python参数指向它不要让 uv 去安装 conda 管理的 Python 解释器二者职责重叠如果项目需要 CUDA 这类系统级依赖继续用 condauv 负责 Python 项目内部依赖更合适使用uv python list可以查看当前 uv 能识别的解释器来源。6. 最佳实践与工程建议6.1 缓存目录纳入“固定资产”管理既然 uv 靠缓存省空间那缓存本身就成了一个重要目录。建议不要把缓存目录随手放在系统临时盘避免被系统清理工具误删磁盘充足时可以保留旧版本缓存方便快速切换版本磁盘紧张时优先用uv cache prune而不是盲目rm -rf整个缓存目录在 CI 服务器上可以把缓存目录挂载为持久化卷加速每次构建。6.2 CI/CD 中优先使用 uvuv 最大的优势之一就是“确定性 快速”。在 CI 流水线里建议steps: - name: Install uv run: curl -LsSf https://astral.sh/uv/install.sh | sh - name: Sync dependencies run: uv sync --frozen--frozen表示严格按uv.lock安装不重新解析依赖版本。这样既能保证构建一致性又能享受 uv 的速度收益。如果你对性能要求更高还可以开启缓存挂载让不同构建任务共享 uv 缓存。6.3 多项目共用依赖时的版本策略uv 的省空间效果在“多个项目依赖版本接近”时最明显。相反如果每个项目依赖的包版本差异巨大缓存中会积累很多版本占用也会增加。工程上建议在同一团队内尽量统一 Python 版本基础依赖如pydantic、requests、loguru尽量统一大版本版本升级时及时清理不再使用的旧版本缓存用uv lock确认依赖锁定后再提交到代码仓库。6.4 文件系统选择如果你本机要大量使用 uv建议Linux 优先使用ext4、xfs等支持硬链接的文件系统Windows 使用 NTFS不要用 FAT32 / exFAT 存放项目或 uv 缓存如果项目在 Docker 容器中确认挂载卷的文件系统类型虚拟机跨主机共享目录时先测试硬链接是否真的生效。6.5 安全与备份提醒硬链接共享数据虽然 uv 默认不可变缓存设计降低了风险但如果你需要对外分发代码、备份项目或在多台机器间同步环境有几点要注意不要把整个.venv目录复制到另一台机器尤其不能用 tar 跨文件系统打包硬链接否则可能丢失链接关系备份项目时只备份源码和pyproject.tomluv.lock环境可以通过uv sync重建不要在共享缓存目录上执行随机权限修改避免其他项目无法访问在部署脚本中对缓存目录的写入和清理操作控制好权限遵循最小权限原则。6.6 用 uv 管理 Python 版本是一个隐藏加分项uv 不仅能创建虚拟环境还能下载、管理多个 Python 版本uv python install 3.11 3.12 uv python pin 3.12 uv run python --version这相当于把pyenv的一部分能力也覆盖了。以后项目换 Python 版本时不用再手动去官网下载安装包。建议新项目直接使用 uv 管理 Python 版本让团队成员的环境尽可能一致。6.7 表格速查venv vs conda vs uv能力venv pipcondauv虚拟环境隔离支持支持支持包安装速度一般一般快磁盘共享复用弱部分平台可用强硬链接Python 版本管理需额外工具支持支持系统级 C/C 依赖不支持支持不支持依赖锁定需手动支持支持团队协作一致性一般中等好7. 总结与下一步学习方向这篇文章从“虚拟环境太多撑爆硬盘”这个真实痛点出发梳理了 uv 解决磁盘占用问题的核心机制统一缓存 硬链接。你已经掌握的关键点包括硬链接是文件系统层面的共享机制多个路径指向同一个 inode不复制物理数据uv 通过缓存目录集中保存包文件并在虚拟环境中用硬链接复用跨文件系统时硬链接失效通过UV_CACHE_DIR可以调整缓存位置常见报错如“managed by uv”、环境未激活、cache 过大都有对应的排查思路在 CI、团队协作、多项目管理中uv 的锁文件和缓存机制都有实际价值。下一步建议你直接动手做一个小实验创建两个 uv 项目都依赖requests然后用ls -li或stat查看两个环境中requests包的 inode 是否一致。把这个实验做一遍比看十篇文章都管用。再往后可以继续学习uv build打包发布、uvx运行临时工具、以及 uv 与 Docker 镜像构建的结合方式。这些东西在真实工程中非常实用也能进一步发挥 uv 的效率优势。如果这篇文章对你有帮助可以收藏备用。遇到 uv 相关的新问题也欢迎在评论区交流讨论。
uv硬链接机制：让Python虚拟环境磁盘占用暴减的工程实践
1. 背景与核心概念1.1 虚拟环境为什么这么“吃”硬盘做 Python 开发的同学应该都有过这种体验每新建一个项目就习惯性地执行一次python -m venv .venv或者用 PyCharm 自动创建解释器然后pip install xxx装一堆依赖。项目一多问题就来了。以我手头一台开发机为例做了大概 20 个 Python 项目后~/.venvs、各个项目目录下的venv、加上偶尔用 conda 建的几个环境加起来轻松超过 30GB。更夸张的是其中有 8 个项目都用的是requests、numpy、pydantic这类重复依赖每个环境里都完整复制了一份同名包文件。问题本质在于常规的venvpip流程会在每个虚拟环境里生成一份独立的site-packages副本。同一个包1 个项目装一次就是一份物理拷贝10 个项目就是 10 份。包里面很多是纯 Python 源码、编译后的.so、.pyd文件体积并不小重复 10 次之后非常可观。有人会说那我用--system-site-packages共享系统包可以但会牺牲环境隔离A 项目升级了一个包B 项目可能直接跑不起来并不适合多数正规工程。也有人会想到 condaconda 在 Linux 上确实会用硬链接减少重复占用但 Windows 和部分场景下效果不稳定而且 conda 自带一个庞大的基础环境开销也不小。相比之下uv提供了一个更干净的答案把包统一放到一个缓存目录里然后通过硬链接把它们“塞”进各个虚拟环境。底层文件只有一份环境里看起来却像各有一份。1.2 uv 是什么uv是一个用 Rust 编写的 Python 包与项目管理工具由 Astral 团队开发。由于底层实现效率高、并发处理好它的核心卖点很直接比 pip 快一个数量级。但 uv 并不只是“快”它至少做了这几件事包安装兼容pip的安装行为但速度更快虚拟环境管理直接创建venv还能下载并管理指定的 Python 解释器版本项目依赖管理基于pyproject.toml和锁文件uv.lock管理依赖工具运行通过uvx快速运行一次性工具。我在实际项目里用 uv 之后最直观的感受有两个一是装包快了很多二是磁盘占用明显下降。第二个感受正是来自 uv 的缓存硬链接机制。1.3 硬链接是什么硬链接是操作系统文件系统层面的概念。简单说一个文件在磁盘上由inode表示而文件名只是指向inode的“目录项”。硬链接就是在同一个文件系统里让多个文件名指向同一个inode。举个例子echo hello a.txt ln a.txt b.txt此时a.txt和b.txt是两个不同的路径但它们的inode一模一样。修改任意一个另一个也会变删除其中一个另一个仍然存在只有当所有指向该 inode 的目录项都被删除时数据才真正释放。这和“复制文件”完全不同。复制是产生两份物理数据硬链接只是增加了“门牌号”数据始终只有一份。1.4 uv 如何利用硬链接省空间uv的做法可以理解为“集中仓储 门牌分发”下载的 wheel 包和解析后的包文件统一存放在 uv 缓存目录创建虚拟环境并安装依赖时uv 不把包文件整体复制一遍而是在缓存目录和site-packages之间创建硬链接因为硬链接不复制数据10 个环境装同一个requests物理数据只有一份。需要说明的是硬链接只能在同一文件系统内生效。如果缓存盘和项目盘不是同一块磁盘uv 会回退为复制文件这种情况下磁盘占用还是会增长。2. 环境准备与安装 uv2.1 安装 uvuv 的安装方式很多官方推荐用脚本安装。macOS / Linuxcurl -LsSf https://astral.sh/uv/install.sh | shWindows PowerShellpowershell -ExecutionPolicy ByPass -c irm https://astral.sh/uv/install.sh | iex如果你已经安装了 Python也可以通过 pip 安装 uvpip install uvmacOS 用户还可以用 Homebrewbrew install uv安装完成后打开一个新的终端窗口验证一下uv --version正常情况下会输出类似uv 0.5.x (c...)具体小版本号以你安装时为准。uv 的 CLI 还在快速迭代中少量命令的参数细节可能有变化但本文覆盖的uv venv、uv init、uv add、uv sync属于核心命令短期内稳定性是有保障的。2.2 验证安装与查看核心目录uv 安装后本机主要会用到几个目录~/.local/bin或%USERPROFILE%\.local\binuv 可执行文件所在位置~/.cache/uv或%LOCALAPPDATA%\uv\cache包缓存目录~/.local/share/uv/python或特定平台目录uv 管理的 Python 解释器。查看缓存目录位置uv cache dir我建议你先执行一下这条命令记住输出路径。后面排查“磁盘占用没变小”时大概率要看这里。2.3 uv 与 conda / venv 的定位区别这里先区分清楚避免误解venvPython 自带的虚拟环境工具管环境但不管包缓存和解释器版本conda完整的环境和依赖管理方案能管 Python 解释器、C 库、二进制依赖但环境体积大uv可以替代venvpippyenv的部分能力定位更像“现代 Python 工程链路”但它不解决非 Python 的 C/C 库依赖问题这方面还是 conda 更强。如果你的项目有复杂的系统级二进制依赖比如 CUDA、OpenCV 编译库那么 conda 生态仍然有优势。如果你的项目主要是纯 Python 依赖uv 的体验会清爽很多。3. 硬链接原理深入拆解3.1 从 inode 讲起在 Linux / Unix 系文件系统里inode是保存文件元信息的结构包括文件大小、权限、数据块位置等。文件名本身不存数据它只是一个映射。下面我们做一个真实验证。在任意目录创建两个文件并建立硬链接echo hardlink test origin.txt ln origin.txt link.txt ls -li origin.txt link.txt输出中第一列就是 inode 编号两个文件是相同的例如4828347 -rw-r--r-- 2 user user 14 Apr 24 10:00 link.txt 4828347 -rw-r--r-- 2 user user 14 Apr 24 10:00 origin.txt再查看链接数stat -c %i %h %s %n origin.txt link.txt输出中第二列是硬链接数正常情况下是2。把origin.txt删掉再查看link.txtrm origin.txt cat link.txt数据还在因为link.txt仍然指向同一个inode。这就是 uv 能省空间的底层逻辑多个虚拟环境中的同名包文件其实都指向缓存里同一个 inode。3.2 硬链接为什么能省空间我们用一个直观对比来看。假设缓存的requests包解压后是 1MB。使用传统pip项目 A 的 venv 里复制 1MB项目 B 的 venv 里复制 1MB项目 C 的 venv 里复制 1MB。总占用约 3MB而且还有 pip 自己的缓存目录进一步放大占用。使用 uv缓存目录里有 1MB 原始数据项目 A / B / C 的site-packages/requests/只是三个硬链接目录项物理磁盘上仍然只有 1MB。当然目录和文件除了数据本身还有元数据、目录项等开销所以实际占用不是严格 1MB但相比复制 3 份节省量仍然非常可观。3.3 为什么 uv 可以放心使用硬链接很多人会担心既然硬链接共享数据那项目 A 里的包如果被修改项目 B 是不是也受影响这个担心是对的但 uv 从设计上规避了主要风险uv 缓存中的包文件保持不可变。正常通过 uv 安装依赖时包内容不会被随意改写项目运行时的__pycache__、日志、数据文件通常位于项目自身目录或临时目录不会反向污染缓存如果你手动进入某个虚拟环境去改写包源码确实会影响共享缓存但这是反常规操作一般不做。因此只要按 uv 的标准流程管理项目依赖硬链接带来的隔离风险是可控的。3.4 硬链接的边界条件硬链接不是万能的限制条件如下不能跨文件系统/home和/data若是两个分区就不能互相硬链接部分文件系统不支持FAT32、exFAT 对硬链接支持有限或不支持Windows 上依赖 NTFS如果项目放在 U 盘或移动硬盘上可能无法创建硬链接网络挂载盘NFS、SMB 等网络文件系统是否支持硬链接取决于服务端配置。遇到以上情况时uv 通常会回退为复制文件环境仍然能工作只是省空间效果打折。4. uv 创建虚拟环境的完整实战4.1 创建第一个 uv 环境进入项目目录直接创建虚拟环境cd ~/workspace/demo-project uv venv输出类似Using CPython 3.12.x Creating virtual environment at: .venv Activate with: source .venv/bin/activate这里 uv 会优先寻找本机合适的 Python 版本。如果你机器上没有 uv 满意的解释器可以用uv python install安装一个uv python install 3.12然后指定版本创建uv venv --python 3.12 .venv激活环境的方式和普通 venv 完全一样。Linux / macOSsource .venv/bin/activateWindows PowerShell.venv\Scripts\Activate.ps1如果你不想手动激活也可以直接使用uv runuv 会自动定位.venv并执行命令uv run python --version这种方式在 CI 脚本里尤其方便。4.2 安装依赖在激活环境后像 pip 那样安装包uv pip install requests对比一下同样的安装操作uv 通常比 pip 快很多。原因是它不需要反复下载解析元数据而且大量操作是并发进行的。如果你完全不想激活环境也能直接装uv pip install --python .venv/bin/python requests但说实话这样写比较啰嗦日常使用建议要么激活环境要么用uv adduv sync的项目工作流。4.3 用 pyproject.toml 管理项目依赖uv 更推荐的项目工作流是uv init demo-project cd demo-project uv add requests uv syncuv init会生成一个基本的项目骨架包括pyproject.toml。执行uv add requests后pyproject.toml里会写入依赖声明[project] name demo-project version 0.1.0 description Add your description here readme README.md requires-python 3.10 dependencies [ requests2.32,3, ]同时 uv 会生成一个uv.lock锁文件用于锁定所有传递依赖的精确版本。这样一来团队协作时大家只需要uv sync就能根据uv.lock安装出完全一致的依赖集合。4.4 同一个包在不同环境中的磁盘占用现在我们来模拟“多个项目共用依赖”的场景。# 项目 A mkdir -p ~/workspace/proj-a cd ~/workspace/proj-a uv init uv add requests # 项目 B mkdir -p ~/workspace/proj-b cd ~/workspace/proj-b uv init uv add requests # 项目 C mkdir -p ~/workspace/proj-c cd ~/workspace/proj-c uv init uv add requests三个项目都依赖requests。在传统 pip 流程下这会各自复制一份在 uv 流程下物理数据只有一份缓存。我们可以用一个简单命令验证硬链接关系。以 Linux 为例先找到三个项目里requests包的__init__.pyls -li ~/workspace/proj-a/.venv/lib/python3.12/site-packages/requests/__init__.py ls -li ~/workspace/proj-b/.venv/lib/python3.12/site-packages/requests/__init__.py ls -li ~/workspace/proj-c/.venv/lib/python3.12/site-packages/requests/__init__.py只要它们的 inode 编号相同就说明底层文件确实被硬链接共享了。4.5 实战对比du 验证硬盘占用为了直观感受 uv 的效果我在测试机上用两个方案分别创建了 10 个环境每个都安装requests、numpy、pydantic、httpx四个包然后对比磁盘占用。使用传统 venv pip 的方式du -sh ~/workspace/pip-test/*/输出示例26M ~/workspace/pip-test/proj-01/ 25M ~/workspace/pip-test/proj-02/ ...10 个项目总占用约 260MB。使用 uv 的方式du -sh ~/workspace/uv-test/*/每个项目的.venv看起来并不小13M ~/workspace/uv-test/proj-01/ 13M ~/workspace/uv-test/proj-02/ ...这里要注意du统计的是“目录入口的大小”硬链接会让每个目录看起来都像有 13MB。但是看整体磁盘占用缓存目录才是真正的物理数据所在。用du -sh统计整个 uv-test 目录时由于硬链接不会重复计算同一个 inode结果可能会低于每个子目录大小之和具体要看你的du是否按 inode 去重。更准确的办法是看文件系统剩余空间或者用du -sh --apparent-size与真实占用对比。不过下面这个现象更明显重复创建同版本环境时速度极快因为不需要重新复制文件。如果你在 Windows 上可以用 PowerShell 查看Get-ChildItem .venv\Lib\site-packages\requests -Recurse | Measure-Object -Property Length -Sum真正省了多少取决于你的包大小和项目数量。包多、项目多、版本重复率高时节省一半以上是常有的事。5. 常见问题与排查用 uv 过程中有几个报错是大家很容易遇到的。下面按照“现象 → 原因 → 解决”的顺序整理成表。问题现象常见原因解决思路执行uv命令提示找不到命令安装后没有重开终端或 PATH 未包含 uv 目录重新打开终端检查~/.local/bin是否在 PATH报错this python installation is managed by uv and should not be modified.试图用 pip 或其他工具直接修改 uv 管理的 Python 解释器不要手动改受管 Python使用uv pip install或uv add提示“虚拟环境未激活”或找不到.venv当前 shell 没激活环境或 IDE 解释器未指向.venv执行source .venv/bin/activateVS Code 选择解释器为.venv路径硬链接失败磁盘占用没有降低uv 缓存目录和项目不在同一文件系统设置UV_CACHE_DIR到同一分区或接受复制模式uv cache 目录越来越大历史版本缓存未清理执行uv cache prune或uv cache clean无法创建虚拟环境提示只有 Python 2.7系统里默认 Python 太老用uv python install 3.12安装新版本解释器uv sync时依赖解析慢或超时网络问题或镜像源不稳定配置国内 PyPI 镜像源或使用UV_DEFAULT_INDEX环境变量conda 创建的虚拟环境里无法正常使用 uv两套环境变量相互干扰激活 conda 环境后再安装 uvuv 的 Python 解释器独立管理5.1 “this python installation is managed by uv” 报错这个报错很关键。uv 下载并管理的 Python 解释器不希望你用pip之类的工具直接修改它。原因很简单解释器和包缓存是全局共享的手动修改会影响其他环境也破坏了 uv 的不可变缓存假设。解决办法# 不要这样 pip install flask # 应该这样 uv pip install flask如果你必须在托管 Python 里用 pip可以安装一个独立 Pythonuv python install 3.12 uv venv --python 3.12 .venv source .venv/bin/activate此时虚拟环境里的 Python 是可正常使用的但建议仍然优先用 uv 安装包。5.2 环境激活问题第一次用 uv 的人经常卡在“明明创建了环境但python还是系统版本”的问题上。排查顺序确认.venv存在ls -la .venv/bin/激活环境source .venv/bin/activate查看which python确认路径指向.venv在 VS Code 里按CtrlShiftP选择Python: Select Interpreter手动选择.venv路径。如果不想每次激活直接用uv run python xxx.py最省心。5.3 硬链接跨磁盘失败uv 的缓存目录默认放在用户主目录下。如果你的项目放在另一个分区比如/data/projects而主目录在/home那么硬链接跨文件系统不成立uv 会复制文件。解决办法是调整缓存目录位置export UV_CACHE_DIR/data/uv-cache uv cache dir把它放到和项目同一个分区里即可。Windows 上同理可以设置环境变量$env:UV_CACHE_DIR D:\uv-cache注意UV_CACHE_DIR只影响缓存uv 管理的 Python 解释器仍然在用户目录下不过 Python 解释器本身也有硬链接复用机制影响相对小。5.4 uv cache 太大怎么办uv 的缓存可以安全清理清理后只是需要重新下载包不影响已创建的环境。uv cache prune这个命令只删除不再被任何环境引用的缓存。如果确实要全部清空uv cache clean清空后后续uv sync会重新下载依赖速度就会慢一些。建议在磁盘实在紧张时再做全量清理。5.5 迁移已有虚拟环境已经用 venv 建好的环境想迁移到 uv 怎么办我的建议是不要尝试“搬”而是重建在原项目里导出依赖清单用 uv 初始化新项目环境安装依赖并验证。如果之前用的是requirements.txt可以直接uv pip install -r requirements.txt如果之前是手动管理建议借机整理成pyproject.toml一劳永逸。5.6 与 conda 并存注意事项uv 和 conda 是可以共存的但要注意conda 环境里的python是 conda 管理的uv 也能通过--python参数指向它不要让 uv 去安装 conda 管理的 Python 解释器二者职责重叠如果项目需要 CUDA 这类系统级依赖继续用 condauv 负责 Python 项目内部依赖更合适使用uv python list可以查看当前 uv 能识别的解释器来源。6. 最佳实践与工程建议6.1 缓存目录纳入“固定资产”管理既然 uv 靠缓存省空间那缓存本身就成了一个重要目录。建议不要把缓存目录随手放在系统临时盘避免被系统清理工具误删磁盘充足时可以保留旧版本缓存方便快速切换版本磁盘紧张时优先用uv cache prune而不是盲目rm -rf整个缓存目录在 CI 服务器上可以把缓存目录挂载为持久化卷加速每次构建。6.2 CI/CD 中优先使用 uvuv 最大的优势之一就是“确定性 快速”。在 CI 流水线里建议steps: - name: Install uv run: curl -LsSf https://astral.sh/uv/install.sh | sh - name: Sync dependencies run: uv sync --frozen--frozen表示严格按uv.lock安装不重新解析依赖版本。这样既能保证构建一致性又能享受 uv 的速度收益。如果你对性能要求更高还可以开启缓存挂载让不同构建任务共享 uv 缓存。6.3 多项目共用依赖时的版本策略uv 的省空间效果在“多个项目依赖版本接近”时最明显。相反如果每个项目依赖的包版本差异巨大缓存中会积累很多版本占用也会增加。工程上建议在同一团队内尽量统一 Python 版本基础依赖如pydantic、requests、loguru尽量统一大版本版本升级时及时清理不再使用的旧版本缓存用uv lock确认依赖锁定后再提交到代码仓库。6.4 文件系统选择如果你本机要大量使用 uv建议Linux 优先使用ext4、xfs等支持硬链接的文件系统Windows 使用 NTFS不要用 FAT32 / exFAT 存放项目或 uv 缓存如果项目在 Docker 容器中确认挂载卷的文件系统类型虚拟机跨主机共享目录时先测试硬链接是否真的生效。6.5 安全与备份提醒硬链接共享数据虽然 uv 默认不可变缓存设计降低了风险但如果你需要对外分发代码、备份项目或在多台机器间同步环境有几点要注意不要把整个.venv目录复制到另一台机器尤其不能用 tar 跨文件系统打包硬链接否则可能丢失链接关系备份项目时只备份源码和pyproject.tomluv.lock环境可以通过uv sync重建不要在共享缓存目录上执行随机权限修改避免其他项目无法访问在部署脚本中对缓存目录的写入和清理操作控制好权限遵循最小权限原则。6.6 用 uv 管理 Python 版本是一个隐藏加分项uv 不仅能创建虚拟环境还能下载、管理多个 Python 版本uv python install 3.11 3.12 uv python pin 3.12 uv run python --version这相当于把pyenv的一部分能力也覆盖了。以后项目换 Python 版本时不用再手动去官网下载安装包。建议新项目直接使用 uv 管理 Python 版本让团队成员的环境尽可能一致。6.7 表格速查venv vs conda vs uv能力venv pipcondauv虚拟环境隔离支持支持支持包安装速度一般一般快磁盘共享复用弱部分平台可用强硬链接Python 版本管理需额外工具支持支持系统级 C/C 依赖不支持支持不支持依赖锁定需手动支持支持团队协作一致性一般中等好7. 总结与下一步学习方向这篇文章从“虚拟环境太多撑爆硬盘”这个真实痛点出发梳理了 uv 解决磁盘占用问题的核心机制统一缓存 硬链接。你已经掌握的关键点包括硬链接是文件系统层面的共享机制多个路径指向同一个 inode不复制物理数据uv 通过缓存目录集中保存包文件并在虚拟环境中用硬链接复用跨文件系统时硬链接失效通过UV_CACHE_DIR可以调整缓存位置常见报错如“managed by uv”、环境未激活、cache 过大都有对应的排查思路在 CI、团队协作、多项目管理中uv 的锁文件和缓存机制都有实际价值。下一步建议你直接动手做一个小实验创建两个 uv 项目都依赖requests然后用ls -li或stat查看两个环境中requests包的 inode 是否一致。把这个实验做一遍比看十篇文章都管用。再往后可以继续学习uv build打包发布、uvx运行临时工具、以及 uv 与 Docker 镜像构建的结合方式。这些东西在真实工程中非常实用也能进一步发挥 uv 的效率优势。如果这篇文章对你有帮助可以收藏备用。遇到 uv 相关的新问题也欢迎在评论区交流讨论。 
