先还原一个场景你在 PyCharm 的 Terminal 或 Python Console 里跑pip install requests结果直接甩出一行OSError: [Errno 122] Disk quota exceeded。我遇到这报错的时候第一反应和大多数人一样——赶紧敲df -h结果磁盘明明还剩一大半再装一次照样原地报错。这种“磁盘没满却提示空间不够”的诡异情况十有八九不是磁盘容量问题而是文件系统的配额机制在拦路。这篇文章不是简单给个“删缓存”的偏方我会把这行报错的底层原因、排查思路、PyCharm 场景下的特殊坑以及一整套可落地的处理方案都过一遍。内容偏实战适合在 PyCharm 里装第三方包遇到过类似报错的开发者也适合用 WSL、远程解释器、公司开发机受限环境的同学参考。1. 错误定性Errno 122 与“磁盘满”的本质差异1.1 配额机制的两条线容量配额和 inode 配额先说结论Errno 122对应的英文是EDQUOT在 Linux 系统上表示Disk quota exceeded也就是磁盘配额超限。它不是“这块盘满了”而是“你这个用户或你这个组、这个目录在这块盘上被允许使用的额度用完了”。可以把配额想象成一张储值卡卡里的额度是管理员给你划好的比如 10GB你在这台机器上的家目录最多只能写 10GB哪怕这块硬盘本身还有 200GB 空闲系统也不会让你继续写。内核在写入数据块的时候会检查 UID用户 ID对应的已用空间是否超过限制超了就抛EDQUOT。这里要特别注意一点配额通常有两条检查线。第一条是容量配额限制总字节数超了之后写任何新文件都会报错。第二条是 inode 配额限制文件总数。很多人不知道这条线结果磁盘空间明明还剩不少但因为小文件太多把 inode 额度占满了同样会报 quota 相关错误。判断到底是哪条线超限后面第 2 章会给命令。很多教程只让你清缓存、删大文件却忽略了“文件数量超限”的场景导致怎么删都不起作用。1.2 PyCharm 控制台为什么容易撞上配额PyCharm 的项目默认都建在用户主目录下虚拟环境.venv也基本都在项目目录内。如果你跑pip install时用的是系统自带的 pip 或者用户级环境安装的包还会被扔到~/.local/lib/python3.x/site-packages这种用户目录里。问题就在这配额通常限制的就是/home/用户名这个家目录或者/tmp这类共享分区PyCharm 创建的.venv、下载的包缓存、项目的.idea索引全都在家目录里pip install执行过程中实际上要写三块地方下载 wheel 包时写缓存目录解压构建时写临时目录/tmp或TMPDIR最终安装时写虚拟环境的site-packages。这三处只要有任何一处落在受限配额的分区里安装就会失败。很多人在 PyCharm 里装包报配额问题其实不是某个包特别大而是家目录长期堆积了太多缓存和旧环境终于在一次安装时触发了上限。1.3 不同环境下这个错对应的“配额”在哪Errno 122在不同环境下要排查的配额位置完全不同千万别一上来就死磕本机磁盘。运行环境配额最可能限制的位置备注普通 Linux 桌面 / 服务器/home/用户名、/tmp、项目所在挂载点最常见场景服务器开发环境尤其典型WSL / WSL2WSL 的 Linux 文件系统/挂载点Windows 和 Linux 文件互相访问走不同路径配额规则也不同Windows 公司域环境C:\Users\用户名或映射的网络盘NTFS 配额默认不启用但公司策略可以强制开启PyCharm SSH 远程解释器远程服务器上的家目录或项目目录安装动作发生在远端本机磁盘再空也没用PyCharm Docker 解释器容器内挂载的 volume 或容器层如果挂载了宿主机的受限目录同样会报 quota提一个容易混淆的报错同样是 pip 安装失败Windows 下常见的OSError: [WinError 32]是“文件被另一个进程占用”和磁盘配额没关系。两者现象都是装不上但处理方向完全不同。遇到WinError 32时优先考虑是不是杀毒软件、PyCharm 索引进程或者某些 .exe/.dll 文件被锁住而本文讨论的Errno 122重心始终在磁盘配额上。2. 排查链路先确认是谁、在哪个分区、用了多少配额2.1 确认系统的配额类型和当前用量遇到Errno 122我建议不要直接清缓存先花三分钟做一次系统体检。第一步是看磁盘真实使用情况# 看磁盘容量是否真的满了 df -h # 看 inode 是否耗尽文件数量超限时这里会显示使用率接近 100% df -i # 看当前用户的磁盘配额如果系统安装了 quota 工具 quota -s -u $(whoami)df -h输出里磁盘明明有剩余空间但报错仍是配额问题这种情况多半是 quota 限制而不是物理空间限制。quota -s会显示类似Disk quotas for user zhangsan (uid 1000): Filesystem blocks quota limit grace files quota limit grace的内容重点关注blocks那一行的quota和limit列。如果blocks已经顶到quota说明容量配额用完了。如果files列的数字撞到上限则是 inode 配额用完了。有些公司开发机用的是 Lustre 这类并行文件系统没有传统的quota命令需要用lfs quota -u 用户名 /挂载点来查。如果你敲quota提示命令不存在先想一想这台机器是不是特殊文件系统。2.2 把 pip 的读写路径一条条列出来第二步是弄明白 pip 在本次安装中到底往哪些目录写。pip 写文件的位置主要有三处我把默认路径整理成了表用途LinuxmacOSWindows下载缓存目录~/.cache/pip~/Library/Caches/pip%LOCALAPPDATA%\pip\Cache临时构建目录$TMPDIR默认/tmp$TMPDIR%TEMP%包安装目录venv 的site-packages或~/.local/lib/python3.x/site-packages同 Linuxvenv\Lib\site-packages另外如果你在~/.pip/pip.conf或~/.config/pip/pip.conf里配置过cache-dir和timeout实际缓存路径可能已经和默认值不一样了。可以用下面两个命令快速确认 pip 当前的真正行为# 查看 pip 实际使用的缓存路径和缓存大小 pip cache info # 确认当前虚拟环境里 python 和 pip 的真实路径 which python which pip我看到过很多人明明在 PyCharm 里创建了.venv但实际跑pip的时候调用的却是/usr/bin/pip——环境变量 PATH 的顺序问题导致包被装到了系统目录而不是虚拟环境。这种“装错地方”的情况如果叠加配额限制排查起来相当迷惑。2.3 用文件量级判断真正的空间大户第三步是找出家目录里真正的体积大头。这一步的核心思路是不要靠猜直接量化。# 看整个家目录用了多少空间 du -sh ~ # 列出家目录下占用空间最大的前 20 个隐藏目录 du -sh ~/.[!.]* 2/dev/null | sort -hr | head -20 # 重点检查 pip 缓存、用户级 Python 包、虚拟环境 du -sh ~/.cache/pip ~/.local ~/.venv 2/dev/null我实测过很多次真正的“元凶”高度集中在两类~/.cache/pip这个目录最容易被忽视。pip 默认会缓存下载过的 wheel 包装过 TensorFlow、PyTorch、OpenCV 这类大包之后缓存动辄 2GB 到 5GB。装过几十个包的老环境缓存超过 10GB 也不稀奇。旧虚拟环境项目迭代几次之后项目目录里可能残留了好几个venv、.venv、venv2之类的环境。每个环境里都装着一整套依赖包加起来非常可观。如果du -sh ~显示总量已经压在配额线附近那就别犹豫直接进入下一步处理。3. 第一层处理缓存清理与路径搬家3.1 pip 缓存有多大、怎么快速清先做最没有副作用的操作清缓存。pip 20.1 以上版本自带了缓存管理命令非常好用# 查看缓存占用大小和位置 pip cache info # 列出缓存里都有哪些包 pip cache list # 一键清空所有缓存 pip cache purgepip cache purge会删除本虚拟环境对应的 pip 缓存目录下所有文件。清完之后缓存目录占用的配额会立刻释放。如果你是第一次用这个命令建议先pip cache info看一下大小你大概率会被它的体积惊到。不过这里有个必须说清楚的逻辑清缓存只是把“过去下载过的包”删掉不会影响已经安装好的环境。如果这次安装失败是因为写缓存那一刻触发了配额那么清掉缓存之后重新执行pip install通常会顺利通过。但如果安装失败是因为虚拟环境的site-packages已经写不进数据了那么清缓存只能释放一小部分空间不一定够用要看具体项目。3.2 让 pip 换一个缓存目录一次配置永久生效清缓存是治标把缓存挪到配额宽松的分区才是治本的第一步。pip 支持通过环境变量PIP_CACHE_DIR指定缓存目录也可以写进 pip 配置文件。我推荐把这些配置写进~/.pip/pip.confLinux或%APPDATA%\pip\pip.iniWindows[global] cache-dir /workspace/pip-cache timeout 30如果你是临时装一个包也可以直接在命令行里加参数# 临时指定缓存目录装完不写默认缓存 pip install requests --cache-dir /workspace/pip-cache # 或者完全跳过缓存下载后直接安装不留下任何缓存文件 pip install requests --no-cache-dir关于--no-cache-dir我的建议是只用于偶发救火不要长期依赖。它虽然不写缓存但每次安装都要重新下载遇到网络不稳的时候会非常折磨人。更好的习惯是给 pip 找一个“够大且不受限”的缓存分区然后一劳永逸地在配置里写死。3.3 PyCharm 侧的环境变量和装包方式调整在 PyCharm 里你可能会在三个地方执行 pip 操作底部 Terminal、Python Console、左侧的 Python Packages 工具窗口。它们的执行机制不太一样但都共享同一个解释器的环境变量。如果你希望 PyCharm 里所有 pip 行为都统一使用新的PIP_CACHE_DIR可以在解释器配置里加上环境变量打开File - Settings - Project - Python Interpreter。在当前解释器那一行点击 “Show All”不同版本入口略有不同一般在解释器下拉框旁边。选中解释器后找到 Environment Variables 的编辑入口。新增一个环境变量键为PIP_CACHE_DIR值为你规划的缓存目录比如/workspace/pip-cache保存后重启 PyCharm 生效。这里有个实操经验PyCharm 的 Terminal 会继承你在终端里export的变量但 Python Packages 工具窗口不一定继承你临时 export 的环境变量。所以最稳妥的做法是把变量写进 pip.conf 或解释器的 Environment Variables 里而不是每次在 Terminal 里手动 export。另外Python Console 里跑!pip install xxx和 Terminal 里跑pip install xxx的前后目录不一定完全一样。遇到奇怪报错的时候先%pwd看一下当前工作目录再去确认日志里的路径到底指向哪里。4. 根治方向虚拟环境重建与解释器重定位4.1 虚拟环境体积为什么是最后一只大象清完缓存、挪完缓存目录之后如果配额还是不够那问题基本就出在虚拟环境和已安装的包上。一个空虚拟环境本身只有几十 MB但你把它喂饱之后就是另一回事。举个例子一个做数据分析的 PyCharm 项目.venv里装了 NumPy、Pandas、scikit-learn、Matplotlib、Jupyter 这些包体积通常能到 1GB 到 2GB。如果项目涉及深度学习装了 PyTorch 或 TensorFlow 全家桶.venv突破 5GB 是很正常的。多个虚拟环境叠加、加上项目目录里的数据文件和 PyCharm 索引很容易就把 10GB 的配额挤爆。所以从根治角度讲有两种思路删掉不用的旧环境保留当前在用的环境把当前环境整体迁移到没人占用配额的大分区再通过软链接让项目继续用。4.2 venv 迁移 软链接的操作步骤我推荐的做法是先在新位置重建一个干净环境然后用软链接把项目里的.venv指向新位置这样 PyCharm 配置和项目内引用路径都不用大改。Linux / macOS 下的迁移命令# 1. 先把当前环境的包列表导出后面要用 source .venv/bin/activate pip freeze requirements.txt # 2. 把旧环境移动到新分区 mv .venv /workspace/myproject-venv # 3. 在项目目录里做一个软链接指向新位置 ln -s /workspace/myproject-venv .venv # 4. 激活后重新安装依赖 source .venv/bin/activate pip install -r requirements.txt --no-cache-dirWindows 下的思路类似但要用目录联接而不是符号链接:: 1. 备份旧环境目录 robocopy .venv D:\venvs\myproject-venv /E :: 2. 删除原目录 rmdir /s .venv :: 3. 以目录联接方式创建链接 mklink /J .venv D:\venvs\myproject-venv这里有一个坑Windows 下mklink /D创建的是符号链接有些老旧工具不会自动跟随符号链接但mklink /J创建的是 junction 目录联接兼容性好很多。PyCharm 对 junction 的识别也比较友好我建议直接用/J。如果不想用软链接也可以在 PyCharm 里直接添加新位置的解释器然后把项目解释器切过去。这样虽然项目里没有.venv目录了但配置上也不复杂只是相对路径的脚本需要同步改一下。4.3 让 PyCharm 找到新环境迁移完成后需要在 PyCharm 里做一次解释器重新绑定否则 IDE 还在引用旧路径打开File - Settings - Project - Python Interpreter。点击解释器下拉框旁边的 Add Interpreter - Existing Environment。选择新位置的虚拟环境解释器Linux/macOS 选/workspace/myproject-venv/bin/pythonWindows 选D:\venvs\myproject-venv\Scripts\python.exe。确认后 PyCharm 会重新索引环境里的包列表。关于软链接路径有个小提醒如果你在 PyCharm 里直接选.venv/bin/python软链接路径大部分情况下也能正常工作但我遇到过个别场景下 IDE 对软链接解析不准确导致索引失败。稳妥起见在 PyCharm 的解释器设置里直接添加软链接背后的真实路径比如/workspace/myproject-venv/bin/python确定性和可维护性都更好。4.4 远程解释器场景配额在服务器上聊一个容易被忽略的高频场景如果你的 PyCharm 用的是 SSH Interpreter 或 Docker Compose Interpreter那么pip install的执行者其实是远端服务器或容器不是你本地电脑。这时候你本机怎么清缓存、怎么改PIP_CACHE_DIR都无济于事因为报错发生在远端。碰到这种情况正确操作是先通过 SSH 登录到远端机器再重复第 2 章的排查链路# 在远端执行 df -h quota -s -u 你的账号 du -sh ~ du -sh ~/.cache/pip ~/.venv很多公司的开发服务器/home分区是严格配额的但/data、/workspace、/opt这些共享分区往往没有配额或者配额非常宽松。这时候把远端项目目录和虚拟环境移动到宽松分区再在 PyCharm 里把远程解释器的映射路径改过来配额问题就彻底解决了。Docker 解释器也类似如果容器内的项目目录是从宿主机挂载进来的而宿主机那个挂载点恰好有配额写入照样会报 quota如果容器用的是独立卷或容器层那就不用看宿主机的配额重点看容器的镜像 layer 是否被写满。5. 预防思路目录规划和常规清理节奏5.1 项目、环境、缓存三分离的目录习惯踩过的坑多了之后我现在对新机器、新项目有一个固定的目录习惯项目代码放在工作区/workspace/projects/xxx虚拟环境统一放/workspace/venvs/xxx-venv不散落在各个项目目录pip 缓存统一放/workspace/pip-cache这样的好处是配额到底在哪块、每个部分占了多少一眼就能看明白。更重要的是当某个区域配额紧张时你不用在几十个项目里逐个翻.venv和__pycache__。PyCharm 在每个项目创建时都可以指定虚拟环境位置勾选New environment using Virtualenv后手动把路径改成/workspace/venvs/xxx-venv即可整个过程并不比默认方案多花时间。5.2 一套可以上手的月度清理节奏我个人的清理节奏是每个月做一次花十分钟基本不会遇到配额告急的情况执行pip cache purge清掉下载缓存用du -sh /workspace/venvs/*扫一遍所有虚拟环境把三个月不碰的环境归档或删除用find . -type d -name __pycache__ -prune -exec rm -rf {} 清掉项目里的 Python 字节码缓存检查.pytest_cache、.mypy_cache、.hypothesis这类测试缓存目录这几个目录跑几次测试就能攒出几百 MB 的小文件。如果你的配额是因为小文件太多导致的 inode 超限不用纠结空间不够多删目录和文件本身就能缓解。这也是为什么我建议定期清理__pycache__和测试缓存而不是只盯着大包删。5.3 踩坑记录几条容易绕远路的弯路最后分享几个我在实际处理中遇到过、也希望你避免的坑不要暴力删除~/.cache下的所有内容。那个目录里不止有 pip 的缓存还有别的重要数据。清理时尽量用pip cache purge或者只删~/.cache/pip这一个子目录不要整个端掉。不要为了绕过配额就给 pip 打开--no-binary :all:。这个参数会让 pip 从源码编译安装编译过程会在临时目录生成大量中间文件占用的配额和耗时反而更大不是个聪明的取舍。报错之前先确认 pip 到底装在哪个环境里。很多人pip install用的 pip 和 PyCharm 解释器里的 python 根本不是同一个装完发现包没生效顺手再用解释器装一遍最终配额被两份包撑爆。还有一个容易误判的点如果报错行里出现Defaulting to user installation because normal site-packages is not writeable说明当前 pip 对应的 Python 环境对site-packages没有写权限pip 自动改用用户目录安装。这种时候包会被装进~/.local也会消耗家目录配额。这种报错经常出现在系统 Python 或一些发行版默认锁定了系统环境的情况下解决方向要么是建个虚拟环境把依赖隔离进去要么是给特定 Python 环境加写权限无论如何都别硬着头皮用系统 pip 硬怼否则家目录配额很快又会超限。我在实际处理中感受最深的一点是Errno 122这类配额报错真正卡住人的往往不是解决方案本身而是大家一开始都习惯把“磁盘满”和“配额超限”混为一谈导致排查方向完全跑偏。只要先确认配额类型、再定位 pip 的写入路径、最后按“缓存清理、缓存搬家、环境迁移”的顺序来操作绝大多数场景都能在十分钟内收工。下次 PyCharm 控制台再抛这行红色报错你已经有完整的处理链路了。