兄弟看到PermissionError: [Errno 13] Permission denied这一行是不是瞬间头皮发麻别急这基本上是每个玩 Python 的人都会碰到的一道坎尤其是当你满心欢喜地 clone 了一个开源项目准备用pip install -r requirements.txt搞定所有依赖时这个报错就像一盆冷水。你得知道这个错误本身不可怕可怕的是你不知道它为什么出现然后瞎试一通最后把 Python 环境搞得一团糟。这篇文章不打算讲什么高深理论就是纯经验分享。我会带你从报错的本质出发把底层权限逻辑、实际解决步骤、以及那些“网上没明说”的坑都过一遍。读完之后你不仅能在三分钟内解决眼前的问题还能避免未来因为“权限”这俩字重蹈覆辙。1. 问题全貌PermissionError 到底在“嚎”什么1.1 错误信息的真实含义没错就是字面意思拒绝访问。但拒绝的是谁是你的当前用户。为什么拒绝因为你当前运行的 Python 进程或者 pip被操作系统判定为“没有权限在目标目录里写入文件”。完整的报错通常是这样的ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: /usr/local/lib/python3.9/site-packages/xxx Consider using the --user option or check the permissions.看到没有它甚至把提示都给你了。但很多人视而不见直接去搜“PermissionError 怎么解决”然后得到一个“以管理员身份运行”的“万能答案”。这里我可以直接告诉你在 Python 的世界里sudo pip install或者是“右键管理员运行 CMD 再 pip install”是最容易把自己带进阴沟里的操作。咱们后面细说。1.2 为什么 pip 没有权限聊聊 Windows、macOS、Linux 的“地盘”区别这个错误和操作系统强相关但归根结底就一句话Python 的包安装目录属于“系统级”或者“公共目录”当前用户只有读取权没有写入权。Windows 上大多数 Python 是从官网或 Anaconda 安装的默认安装目录在C:\Python\或者C:\Users\你的用户名\Anaconda3\下。当你用普通 CMD 去pip install时如果目标是C:\Python3\Lib\site-packages而你的 Windows 账户不是管理员或者说 UAC 被限制操作系统就会给你穿小鞋。特别是公司电脑IT 部门往往会限制 “Program Files” 和系统盘根的写入权限Python 装在C:\Program Files\Python\下面时踩坑概率极高。Linux/macOS 上这就更常见了。系统自带的 Python比如 macOS 的/usr/bin/python3或者 Ubuntu 的/usr/bin/python3通常挂载在/usr/lib/python3.x/dist-packages。这个目录的权限是root才有的普通用户想写门儿都没有。所以你在自己电脑上跑pip install xxx如果没有激活虚拟环境且没加sudo绝对会报 13 号错误。提示Errno 13 是 POSIX 标准错误码里的“Permission denied”在 Windows 上其实被映射成了OSError(13, Permission denied)。所以无论是哪个系统只要是 13都是权限不够。1.3 容易被忽略的“罪魁祸首”配置文件里的坑还有一种情况不是目录权限真的被锁死而是 pip 本身被搞乱了。你可以在终端里试一下这个命令看看 pip 的“安装策略”pip config list如果你电脑里配置了global.break-system-packages true或者global.target /some/locked/path那也会导致权限报错。另外如果一个项目里的requirements.txt里包含了带--user标志的优秀注释少见但存在或者 pip 的版本太老低于 20.0在处理某些 wheel 包时也会出现意外的目录跳转导致写入失败。说白了权限问题既有“外部”操作系统的锅也有“内部”pip 配置的锅。2. 根因剖析Python 包管理的权限设计逻辑2.1 包安装路径与文件系统权限的关系想要真正解决这个报错你必须明白 pip 的工作逻辑。pip 默认把第三方包放在site-packages目录下。这个目录中你再去尝试访问所属的包文件时会寻找 wheel 包里的dist-info目录来记录版本信息。一旦这个目录的父级也就是site-packages或 Python 安装根目录的写权限缺失pip 的安装流程就会在“解压、写入、注册”的第二步——写入文件时被操作系统以PermissionError: [Errno 13] Permission denied打回。很多新人不理解的是为什么 Linux 系统自带的 pip 装包要sudo这其实是一种保护机制。如果任何人都能往系统 Python 的site-packages里写文件那么任何恶意脚本都能通过覆盖一个常用包比如requests来劫持你的整个 Python 环境。所以操作系统“矫枉过正”地关闭了普通用户的写权限。2.2 三个最常踩坑的场景还原我用三个典型情境帮你脑补一下这个错误出现的全过程场景一Windows 新手上路你刚下载安装完 Python 3.11勾选了“Add Python to PATH”然后在 cmd 里输入pip install requests结果报错。为什么因为你的 Python 装在C:\Python311\但你的登录账户只是普通用户而安装时 installer 默认把C:\Python311\Lib\site-packages的写权限只赋给了Administrator和SYSTEM在部分企业安全策略下更严格。所以你那个普通用户账户写入直接被拒。场景二macOS 系统的“赖皮”行为macOS 自带的是系统级 Python 3.9/usr/bin/clang那套工具链依赖它这个 Python 的site-packages在/usr/local/lib/python3.9/site-packages。新入行的朋友直接用pip install numpy很容易遇到 “cant create or remove files in the current directory: Permission denied”。因为/usr/local/lib在 macOS 的 SIP 保护下默认也是 root 专属的。场景三Linux 服务器上的 Python 环境公司给你的服务器开了普通用户ubuntu你ssh上去之后想跑个项目执行pip install -r requirements.txt结果噼里啪啦一串“PermissionError”。这时候你如果下意识输入sudo pip install -r requirements.txt可能在安装的同时把你系统自带的setuptools或者pip版本给偷偷升级或降级了导致某天系统出问题。2.3 为什么“sudo pip install”是毒瘤在这里必须多句嘴。sudo pip install很爽但它是在site-packages里直接以 root 权限写入。这会绕过venv的隔离机制把包安装到一个“全局公共区域”。如果另一个项目需要不同版本的同一库比如项目 A 需要requests2.20项目 B 需要requests2.31全局安装就只能二选一一升俱升、一降俱降典型的“拆东墙补西墙”。更麻烦的是系统级 Python 的包被替换后可能会导致你操作系统的底层工具比如依赖urllib3的某些管理脚本出现异常。所以在业界共识里除非你在 Docker 容器里否则不要用sudo pip install。3. 解决思路拆解从推荐到兜底四套组合拳针对这些根因解决手段无非四种方向给目标目录赋予当前用户写权限、改变安装目标目录、切换到虚拟环境隔离、或者升级权限运行。每种方法适应场景不同我不打太极直接给你排序。3.1 方案一虚拟环境隔离强烈推荐虚拟环境venv可以创建一个全新的 Python 解释器副本这个副本的site-packages目录由你当前用户创建所以当然有写权限。这是我在所有项目里的默认选择。核心好处从此再也不用担心污染全局环境不同项目的依赖自动隔离完全不需要关心系统 Python 目录权限问题。代价需要一个激活步骤磁盘占用略微增加大概几十 MB。具体命令python -m venv myvenv myvenv\Scripts\activate # Windows 下 source myvenv/bin/activate # Linux / macOS 下 pip install -r requirements.txt3.2 方案二用户级安装--user如果你不想建虚拟环境只是想临时装个包那么 pip 给出了官方选项--user。意思是不装到系统全局的site-packages转而安装到系统当前用户专属的目录下例如 Windows 是C:\Users\你的用户名\AppData\Roaming\Python\Python311\site-packagesLinux 是~/.local/lib/python3.x/site-packages。pip install --user -r requirements.txt这个方案的优点是简单直接加一个参数。缺点在于--user安装的包在某些系统上需要额外配置 PYTHONPATH并且在虚拟环境中会互相干扰在激活虚拟环境时运行pip install --user可能会装进虚拟环境外的全局用户区血泪教训。所以它只适合“我想在系统 Python 里装一个包但不想折腾权限”的快速场景。另外由于--user不会破坏系统包管理器管理的 Python 环境在 POP!_OS、Ubuntu 22.04 这些启用了externally-managed-environment限制的 Linux 发行版上它是一种折中解法。3.3 方案三管理员/root 权限安装谨慎使用Windows右键“命令提示符”或“PowerShell”选择“以管理员身份运行”然后重新pip install。Linux/macOSsudo pip install -r requirements.txt这个方案能冲破一切权限封锁但我在前面已经谴责过它的危害。如果实在要用建议加上--ignore-installed标志就不必了那反而会引发覆盖冲突最好是用pip install --user来替代sudo pip install。不过在某些老掉牙的 CentOS 7 上系统自带的 Python 2.7 是要替换一些软件包的有时候没法用--user那也只能 sudo。但你要清楚自己在做什么而且装完一定要看终端有没有提示 “WARNING: Running pip as the root user can result in broken permissions and conflicting behaviour”。3.4 方案四修正目标目录权限不推荐但应急可用这条只建议在你清楚地知道自己在干什么的情况下使用。比如在 Linux 上你想让这个目录能被普通用户写sudo chown -R $USER:$USER /usr/local/lib/python3.9/site-packages或者给该目录加写权限sudo chmod -R ow /usr/local/lib/python3.9/site-packages但这里面有个致命问题它会破坏该目录原本的“受保护”状态任何用户都可以在里面写文件相当于把一个保险库的密码贴在了门上。而且某些系统比如 macOS 的 SIP会阻止chmod对关键目录生效。所以这个方法属于“饮鸩止渴”仅供单用户电脑上想省事时临时参考。4. 实操演示从零到一完整复现权限修复4.1 先做个快速诊断在你执行任何修复命令之前建议先确认 pip 当前是哪个用户、哪个环境which python which pip python --version如果你发现which pip给出的路径是/usr/bin/pip那就是系统级 pip。如果路径里有venv字样那说明你在虚拟环境里。不同的目标对应的方案完全不同。这里必然要强调激活虚拟环境之前不要跑任何 pip 安装。4.2 步骤一创建虚拟环境以最新 Python 3.11/3.12 为例假设你的项目目录叫my_project依赖文件是requirements.txt。cd my_project python -m venv .venvpython -m venv的作用是调用 Python 标准库venv模块创建.venv目录。在这个目录里包含了一个全新的 Python 解释器环境以及一套独立的site-packages同时也会自动安装基础的pip、setuptools。这里有个小细节如果你同时安装了多个 Python 版本建议用python3.11 -m venv .venv确保创建出来的环境是 Python 3.11 而不是默认的 Python 3.8 之类。我在 Windows 上吃过这个亏乱在 cmd 里用python结果创建的环境是 3.8而项目需求是 3.11。4.3 步骤二激活虚拟环境这是新手最容易懵的一步各个平台激活命令各不相同。WindowsCMD/PowerShell.venv\Scripts\activatePowerShell 里有时还要先解除脚本执行策略不然会报“无法加载文件因为在此系统上禁止运行脚本”。这时候你用管理员身份运行 PowerShell执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser然后再激活。Linux / macOSBash / Zshsource .venv/bin/activate激活成功的标志是终端提示符最前面出现了(.venv)字样例如(.venv) ubuntuserver:~/my_project$看到这个就说明当前 Python 已经是虚拟环境里的了。此时再执行which pip它会指向虚拟环境内的 pip而非全局 pip。4.4 步骤三升级 pip 并安装依赖进入虚拟环境后为了防止 pip 版本太老导致安装某些新包时出现解析错误我一般会先升级 pippip install --upgrade pip然后你再执行那个令人纠结的命令pip install -r requirements.txt这时候你会发现安装过程一路绿灯。因为.venv目录是在当前用户的my_project下当前用户自然有完全的读写权限。整个过程不再需要 sudo也不再需要管理员终端。这就是最标准的现代 Python 工作流。4.5 步骤四验证权限与依赖安装安装完以后你可以通过pip list看包是否齐全或者尝试在解释器里 import 某个包python -c import requests; print(requests.__version__)如果想确认当前包的路径可以用python -c import requests; print(requests.__file__)如果输出路径是/my_project/.venv/lib/python3.11/site-packages/requests/__init__.py说明包被正确地安装在自己的环境里了。如果输出的是/usr/lib/...那说明哪怕虚拟环境是激活状态你也在无意中用了全局包这种情况通常是你用了 Jupyter 内核或者没在 Jupyter 里激活环境这里先不展开。5. 进阶排查权限错误连锁问题与冷门技巧你以为解决完PermissionError就万事大吉啦太天真了。旧的问题解决了新的问题马上来。在这里我特意整理了几个紧密相关的“周边坑”尤其是 2023 年后externally-managed-environment这个报错几乎成了排查权限错误时的热门后继者。5.1 接踵而至的 externally-managed-environment 报错这个报错来自 2023 年之后的新政策。Linux 发行版Ubuntu 23.04 和 Debian 12 等默认给系统 Python 加了一个限制系统 Python 环境被系统包管理器apt管理不允许你用 pip 直接装包。于是你会在执行pip install modelscope或pip install requests时看到一坨长长的错误error: externally-managed-environment This environment is externally managed ... Due to this, activating the virtual environment is required.很多人以为这又是权限错误其实不是这是“状态检查”拦截了 pip 的操作。解决方案很简单创建虚拟环境和上面一样进入后无视该限制。如果你的项目实在不想用虚拟环境并且你确认安全可以在/etc/pip.conf或~/.config/pip/pip.conf中加入[global] break-system-packages true这种做法等于直接告诉 pip我不管系统受管请你强行安装。不推荐但求个明白。使用pip install --user绕过这个检查理论上一样受限于 PEP 668 的限制但部分旧版 pip 不被拦截。所以我建议干脆就强制全部走venv。你如果能通读完这篇文章认真用了虚拟环境那这个externally-managed-environment就永远与你无关了。5.2 Windows 下常见的连锁问题无法加载脚本策略Windows 用户在激活虚拟环境时经常报错.venv\Scripts\activate.ps1 : 无法加载文件 C:\.venv\Scripts\Activate.ps1因为在此系统上禁止运行脚本。这个属于 PowerShell 的执行策略挡路跟 Python 没直接关系。解决办法就是Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这里解释一下RemoteSigned意味着本地脚本可以运行只有从网上下载的脚本才要求数字签名。所以是相对安全的策略。你用这个策略后就能激活虚拟环境权限问题自然不存在了。5.3 Linux/macOS 下被忽略的 Python 安装位置有时候你在 Linux 上明明已经安装了 Python 3.11自己源码编译的却还是报权限错误。原因很可能在于你自己编译的 Python 被放在了/usr/local/bin/python3.11或/opt/python-3.11这个目录本身属于 root 用户普通用户无写权限。这时候哪怕用python3 -m venv .venv也会因为找不到ensurepip模块或者创建失败而报错。所以当你用源码编译的 Python 时建议在 configure 阶段加上--prefix$HOME/.local/python3.11然后再安装到自己的用户目录这样就能避开所有权限问题。或者干脆用 pyenv 管理多个 Python 版本一劳永逸。5.4 冷门但好用的 debug 工具pip -v有一个很实用的排查技巧我强烈建议你在报错时用上pip install -r requirements.txt -v-vverbose会显示 pip 执行过程中的详细日志包括它尝试解析 index、下载 wheel、解压到临时目录、拷贝到site-packages的每一步。当报错出现在“Copying xxx...”这一行时就可以精准定位到是哪个目录的写权限有问题。同样--log 文件路径可以把你难得的错误日志输出到文件方便跨设备求助。6. 经验总结与避坑清单前面该讲的都讲完了这里我用几句掏心窝的话收个尾。6.1 遇到权限错误时的五步检查顺序我踩坑无数之后自己总结了一套排查顺序按这个走基本不出大问题先看报错尾部提示是不是Consider using the --user option如果是说明 pip 已经检测到了权限问题。检查当前是否在虚拟环境中不在的直接python -m venv .venv source .venv/bin/activate。看一下which pip确保用的是你想用的那个 pip而不是因为 PATH 顺序导致用错了环境。如果确认不在虚拟环境且就想立即安装用pip install --user过渡。如果--user也不让装那基本是 PEP 668 限制请毫不犹豫回到第 2 步。6.2 关于修改权限的辩证思考我不赞成动不动就chmod -R 777或者sudo chown这相当于把你家门钥匙插在锁上。单机玩无所谓但如果你在一台多人共用的服务器上这种行为会让安全性和可维护性荡然无存。相对而言虚拟环境什么都不会污染用完之后把.venv文件夹删掉就是项目间互不干扰这应该是你的默认选项。6.3 我自用的第二套备选方案如果你真的是一个刚入门 Python 的新手连“虚拟环境是啥”都还处于懵懂状态那我确实会建议你直接用 Anaconda。它的conda create -n myenv python3.11命令能够自动创建独立环境并且每个环境都自带写权限在 Windows / macOS 上极少出现 PermissionError。虽然 Anaconda 较大但学习阶段的你少折腾一点多把精力放到算法和代码逻辑上性价比其实很高。最后再分享一个小技巧其实很多requirements.txt里的包都可以装到用户默认目录。你可以在requirements.txt文件开头加一行注释提示自己后续执行时要加--user参数但这不是最优解。最优雅的做法是你自己写一个install.bat或install.sh脚本内部固定执行“创建虚拟环境 激活 pip install -r requirements.txt”这三连这样以后拿到任何项目一条命令直接搞定。我在实际开发中就是这么干的省心远不止一点点。