兄弟，看到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，很容易遇到 “can't 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 需要requests==2.20，项目 B 需要requests==2.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-packages，Linux 是~/.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/macOS：
sudo 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 o+w /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 步骤二：激活虚拟环境
这是新手最容易懵的一步，各个平台激活命令各不相同。
Windows（CMD/PowerShell）：
.venv\Scripts\activatePowerShell 里有时还要先解除脚本执行策略，不然会报“无法加载文件，因为在此系统上禁止运行脚本”。这时候你用管理员身份运行 PowerShell，执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，然后再激活。Linux / macOS（Bash / Zsh）：
source .venv/bin/activate
激活成功的标志是，终端提示符最前面出现了(.venv)字样，例如：
(.venv) ubuntu@server:~/my_project$看到这个，就说明当前 Python 已经是虚拟环境里的了。此时再执行which pip，它会指向虚拟环境内的 pip，而非全局 pip。
4.4 步骤三：升级 pip 并安装依赖
进入虚拟环境后，为了防止 pip 版本太老导致安装某些新包时出现解析错误，我一般会先升级 pip：
pip 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-v（verbose）会显示 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 python=3.11命令能够自动创建独立环境，并且每个环境都自带写权限，在 Windows / macOS 上极少出现 PermissionError。虽然 Anaconda 较大，但学习阶段的你少折腾一点，多把精力放到算法和代码逻辑上，性价比其实很高。
最后再分享一个小技巧：其实很多requirements.txt里的包都可以装到用户默认目录。你可以在requirements.txt文件开头加一行注释，提示自己后续执行时要加--user参数，但这不是最优解。最优雅的做法是你自己写一个install.bat或install.sh脚本，内部固定执行“创建虚拟环境 + 激活 + pip install -r requirements.txt”这三连，这样以后拿到任何项目，一条命令直接搞定。我在实际开发中就是这么干的，省心远不止一点点。
