我之前帮一位刚转行做数据分析的读者远程调试环境他的机器上 VS Code、Miniconda、Jupyter 插件全都装好了步骤也基本是照着教程走的结果在终端里第一次敲conda install pandas时直接弹出一屏红色报错EnvironmentNotWritableError: The current user does not have write permissions to the target environment后面还跟着environment location: C:\ProgramData\miniconda3这样的路径。他的第一反应是重装 Miniconda重装完之后一模一样的报错又出现了。问题其实不在 Miniconda 本身也不在教程写错了而在安装和使用过程中你把 conda 装进了一个当前账号没有写权限的目录。这篇文章我会从零开始把 VS Code Miniconda 本地 Jupyter 环境的搭建完整走一遍每个按钮、每条命令都尽量说清楚然后把EnvironmentNotWritableError的成因拆开揉碎给出三套我实测有效的修复方案最后聊聊环境跑通之后我踩过的几个坑和积累下来的使用习惯。文章覆盖 Windows 和 macOS/Linux适合正在学 Python 数据分析、刚接触 conda 环境管理、被 VS Code 环境配置折腾到怀疑人生的读者。1. 为什么我推荐 Miniconda VS Code 这套组合而不是“装好就不折腾”的其他方案先别急着复制命令。动手之前把方案的选型逻辑讲清楚后面出问题时你才知道该往哪个方向排查。1.1 Anaconda、Miniconda 与裸 Python核心差距在环境隔离初学者最容易纠结的一个问题是既然 Anaconda 那么大、那么多预装包为什么很多教程反而推荐体积更小的 Miniconda我的看法是这样。裸 Python 适合临时跑个脚本装几个纯 Python 包完全没问题。但只要项目超过一个或者你同时需要维护 Python 3.8 和 3.11 两个版本、一部分包必须锁定旧版本裸 Python 加全局 pip 就会迅速失控。Anaconda 的优点也恰恰是它的缺点预装了几百个包装完确实开箱即用但这些包的版本是别人替你选的。等你后面装一个新包时Anaconda 频繁提示需要升级或降级现有包环境会变得越来越不可控。Miniconda 只带一个 conda 和一个干净的基础 Python 环境剩下的包按需安装但它完整保留了 Anaconda 最核心的能力——环境隔离。你可以为每个项目单独建一个环境互不干扰。几十 MB 的体积换来的是对 Python 版本和依赖版本的完全掌控。对比项裸 PythonAnacondaMiniconda安装体积约 30MB约 3GB约 80MB多环境隔离不支持支持支持科学计算包需逐个手动安装预装大量按需安装适合场景简单脚本、一次性任务想开箱即用的入门用户希望环境可控的开发者、学习者就我个人的实践经验Miniconda 是投入产出比最高的选择安装速度快环境管理能力不打折即使你是纯新手多敲几条conda create命令很快就能形成肌肉记忆。1.2 VS Code 里的 Jupyter 与浏览器里的 Jupyter差距在工作流浏览器里的 Jupyter Notebook 是经典方案启动后在 localhost:8888 打开页面界面专一、视觉清爽。它的短板在于文件管理和代码补全都相对朴素。你写分析脚本时通常还要开着另一个编辑器项目级操作如 Git 提交、多文件跳转、调试都得靠外部工具完成。VS Code 里的 Jupyter 更像是在一个现代编辑器里嵌入 notebook。左边资源管理器管文件右侧编辑区跑 .ipynb补全和语法诊断由 Python 语言服务提供下方还集成了终端。你在 notebook 里写好一段分析逻辑切到旁边的 .py 文件去抽公共函数然后再回到 notebook 里调用整个过程在同一个窗口里完成。对于数据清洗、快速爬虫原型、机器学习实验这类探索式编程这种整体感能显著提升效率。1.3 这套组合的真正价值一句总结用最小的安装成本获得可复制、可隔离的 Python 环境并用现代编辑器完成 Jupyter 交互式编程。它解决的是三件事让不同项目的依赖互相隔离让代码编写和笔记式实验无缝衔接让环境配置变成可复现的步骤而不是玄学。后面所有操作都围绕这三件事展开。2. Miniconda 安装全流程每一步都盯住“权限”两个字为什么安装一节要单独强调权限因为EnvironmentNotWritableError大概率是安装阶段埋下的雷。安装时多勾一个选项、多用一次 sudo后面就会爆炸。所以这一节我会仔细讲 Windows 和 macOS/Linux 的安装差异。2.1 下载安装包的版本选择Miniconda 官方下载页在 conda 文档站上文件名通常是Miniconda3-latest-系统-架构.后缀。这里有个非常容易忽略的分支问题。Windows 直接选 64-bit 版本除非你的机器还是古董级的 32 位系统。macOS 要看芯片。M1/M2/M3 系列芯片选择Miniconda3-latest-MacOSX-arm64.shIntel 芯片选Miniconda3-latest-MacOSX-x86_64.sh。用苹果芯片强行装 x86_64 版也能跑但会在系统里启用 Rosetta 转译conda 解析依赖时可能出现奇怪的架构冲突。你在终端执行uname -m输出arm64就选 arm64 版输出x86_64就选 x86_64 版。Linux 服务器普遍是 x86_64 架构选对应的 .sh 脚本即可。如果你用的是 ARM 架构的云主机也要注意选 arm64 版本。2.2 Windows 安装的关键选项顺序和路径都不能错Windows 上安装 Miniconda 时Install for:这一步一定要选Just Me。选 Just Me 会把 conda 装到C:\Users\你的用户名\miniconda3这是用户目录你拥有完整写权限。如果选了 All Usersconda 会被装到C:\ProgramData\miniconda3这类系统级目录。日常使用 conda 时创建环境、安装包、缓存包都要往这个目录里写文件而默认情况下你这个账号对这个目录只有读权限于是PermissionError: [Errno 13] Permission denied和EnvironmentNotWritableError就会轮番出现。第二个关键选项是是否把 conda 加入系统 PATH。新版安装器一般会提供注册选项我建议直接勾选注册。如果安装器没有这个选项你可以在 Windows 系统环境变量里手动添加C:\Users\你的用户名\miniconda3和C:\Users\你的用户名\miniconda3\Scripts。如果你的机器上已经装了其他 Python后装的 Miniconda 路径一定要排在旧 Python 前面否则在终端执行python时调用的也许还是旧版本。安装完成后打开一个全新的终端窗口或者 Anaconda Prompt输入conda --version能输出版本号就说明基础安装成功了。2.3 macOS/Linux 的命令行安装与路径指定macOS 和 Linux 推荐用终端安装。下载完 .sh 文件后先确保它有执行权限再运行chmod x Miniconda3-latest-MacOSX-arm64.sh bash Miniconda3-latest-MacOSX-arm64.sh安装器会先展示许可证协议按回车读完输入yes确认。接下来是关键点。安装器会问Installation prefix也就是安装路径。默认值是$HOME/miniconda3对应 macOS 上的/Users/你的用户名/miniconda3、Linux 上的/home/你的用户名/miniconda3。请保持默认。只要安装路径在用户主目录下后面所有 conda 操作都有完整写权限。很多服务器教程喜欢装到/opt/miniconda3或者/usr/local/miniconda3这些目录通常属于 root普通用户只有读权限这就是EnvironmentNotWritableError的高发区。安装器最后会问是否运行conda init输入yes。它会把初始化脚本写进你的 shell 配置让 conda 命令从下次打开终端起自动可用。如果你想立即生效可以执行source ~/.bashrcLinux 下如果执行.sh时报Permission denied先执行chmod x再跑。Ubuntu 等 Debian 系系统尤其常见因为默认下载文件没有可执行权限。2.4 安装后第一件事验证 conda 命令可用每台机器安装完我都建议立刻验证三件事先确认地基是稳的conda --version which conda conda info --envswhich conda的输出很关键。如果你的输出指向/Users/xxx/miniconda3/bin/conda或/home/xxx/miniconda3/bin/conda说明安装到了用户目录权限结构是正常的。如果指向/usr/local/bin/conda或/opt/miniconda3/bin/conda说明之前使用了 sudo 或 Homebrew 安装先别急着继续直接跳到第 5 节的修复方案处理。还有一个和权限无关但会影响体验的事conda 默认源在部分网络环境下下载很慢。如果你感觉创建环境时卡在 download 阶段可以在~/.condarc里配置一个速度快且稳定的镜像源但这不是本节重点后面遇到实际问题时再处理也不迟。3. VS Code 环境配置从安装插件到跑通第一个 notebookMiniconda 就位后进入 VS Code 侧。VS Code 本身没有装的话先去官网下载安装包安装过程没有什么特殊的Windows 上注意勾选“添加到 PATH”选项macOS 上把应用拖到 Applications 即可。接下来是插件和解释器的配置。3.1 两个必装插件Python 和 Jupyter打开 VS Code 扩展面板搜索并安装两个插件Python发布者是 ms-python提供解释器选择、代码补全、语法诊断。Jupyter发布者是 ms-toolsai提供 notebook 文件的编辑和内核管理。这两个都是官方维护的插件名认准发布者不要装错同名第三方扩展。装完后重启窗口。3.2 选择 conda 解释器的正确方式在 VS Code 里打开任意一个 .py 文件按CtrlShiftPMac 上是CmdShiftP输入Python: Select Interpreter并回车。弹出的列表里会显示系统能识别到的所有 Python 可执行文件包括不同 conda 环境下的解释器。这里有一个新手容易误解的地方你只选到 Miniconda 的 base 环境还不够。如果你在终端里新建了一个名为data_env的 conda 环境需要在解释器列表里选择对应的 data_env 解释器。列表没刷出来时点Enter interpreter path手动指过去。Windows 的路径一般是C:\Users\你的用户名\miniconda3\envs\data_env\python.exemacOS/Linux 是/Users/你的用户名/miniconda3/envs/data_env/bin/python。选完以后VS Code 左下角状态栏会显示当前解释器名称点击这个名称也可以随时切换。3.3 创建 notebook 并运行第一段代码在资源管理器里新建一个文件命名为test.ipynb。VS Code 会以 notebook 编辑器打开它。左上角内核区域显示选择内核或者当前 Python 环境的名称点击它选中你刚配置好的 conda 环境。然后输入第一段代码import sys print(sys.executable)按ShiftEnter运行。如果输出的是你 conda 环境里的 python 路径说明 VS Code 到 conda 环境的链路已经通了。到这里你可能会遇到一个新问题环境选好了但运行时报缺少 ipykernel。这是很正常的情况因为 Jupyter 需要内核包才能和解释器通信。3.4 没有 kernel 时 VS Code 会自动处理但你最好知道它做了什么当 VS Code 检测到当前环境没有 ipykernel 时会弹出一个安装提示点一下它会自动往当前环境里装 ipykernel。如果你更愿意用终端手动安装执行conda activate data_env conda install ipykernel两种方式等效但我更习惯手写命令。因为 VS Code 自动安装默认调用 pip而conda install ipykernel是 conda 自己做的依赖解析和该环境下其他 conda 管理包的依赖关系更一致。后续如果你还计划用 conda 管理环境优先用 conda 而不是 pip这个习惯能省掉一大半环境冲突问题。4. EnvironmentNotWritableError 报错深度解析它到底在说什么环境跑通以后再来处理这个全网高频报错。我会按“报错原文逐行读、根因场景分类、不同系统差异、疑难报错区分”四层来拆。4.1 报错原文逐行翻译完整报错通常长这样EnvironmentNotWritableError: The current user does not have write permissions to the target environment. environment location: /opt/miniconda3 uid: 501 gid: 20逐行的意思是EnvironmentNotWritableErrorconda 在往某个环境目录写入时当前用户没有写权限。The current user does not have write permissions to the target environment.当前用户对该目标环境没有写权限。environment locationconda 想写入的目录。这个路径决定了你下一步排查方向。uid和gid当前用户的用户 ID 和用户组 ID主要用来判断目录所有者和当前用户是否匹配。macOS/Linux 上权限由所有权决定目录所有者和当前用户不一致时就可能出现这个报错。Windows 上对应的报错形态通常是PermissionError: [Errno 13] Permission denied原因机制相同只是表述不同。4.2 这个坑为什么偏偏是新手踩新手踩这个坑的最常见原因就是在安装时使用了管理员权限或系统级目录。我在第 2 节反复强调“Just Me”“保持默认路径”就是为这一步提前排雷。但还有一些相对隐蔽的高发场景第一个场景是 macOS 用户使用 pkg 安装包安装 Miniconda。pkg 安装器会默认把环境放到/opt/miniconda3或/usr/local/miniconda3。这些目录的所有者是 root普通用户只有读和执行权限。安装完成后第一次conda install就会报环境不可写。第二个场景是 Linux 用户按照部分网文执行了sudo bash Miniconda3-latest-Linux-x86_64.sh或者安装完又用sudo conda install装过包。sudo 执行会导致 conda 目录下的文件全部归 root 所有之后不带 sudo 跑 conda 写不了目录带 sudo 又会产生新的 root 文件越修越乱。第三个场景是设置了CONDA_ENVS_PATH环境变量指向一个没有写权限的路径。这个变量的优先级很高它会让 conda 把所有新创建的环境放到指定目录如果这个目录在/usr/local/...下而你的账号没有写权限同样会报错。4.3 三种系统下的权限差异不同系统出现权限问题的常见位置不同我用表格整理一下系统常见故障目录正常权限模式报错形态WindowsC:\ProgramData\miniconda3、C:\Program Files...用户目录 C:\Users\用户名\miniconda3PermissionError: [Errno 13] Permission deniedmacOS/opt/miniconda3、/usr/local/miniconda3~/miniconda3EnvironmentNotWritableErrorLinux/opt/miniconda3、/usr/local/miniconda3~/miniconda3EnvironmentNotWritableError判断方法也很直接看报错里environment location的路径再看一下这个目录的所有者。macOS/Linux 执行ls -ld /opt/miniconda3Windows 在资源管理器里右键目录、属性、安全或者用icacls C:\ProgramData\miniconda3查看。如果所有者不是你的用户名后面的修复方案就该安排上了。4.4 和它长得像的报错怎么区分环境问题里还有几个容易混淆的报错排查方向完全不同CondaHTTPError网络或下载源问题和权限无关。看到HTTP 000 CONNECTION FAILED这类字样时检查网络和 conda 源配置。PackageNotFoundError找不到包。通常是包名拼写错误或确实不在当前渠道。pip 报的PermissionError: [Errno 13] Permission denied这是 pip 尝试往系统 Python 目录写文件同样是因为权限但处理方式是在终端加--user参数或者更规范地创建一个虚拟环境后用 pip。区分的关键是看报错里包含的关键词。只有当你看到EnvironmentNotWritableError或者environment location时才意味着问题出在 conda 环境的目录权限这才适合用下一节的方案处理。5. 完整排查与修复三套方案从治标到治本报错理解清楚以后下面按“从局部修复到重装修复”的顺序给出三套完整的解决方案。你可以按实际情况选择。5.1 方案一修改 .condarc把环境和缓存目录指向用户目录适合 conda 装在共享路径下但你不想动它的场景比如公司机器、服务器上 conda 由管理员统一安装。打开或新建用户目录下的~/.condarc文件Windows 上是C:\Users\你的用户名\.condarcmacOS/Linux 上是~/.condarc。添加以下内容envs_dirs: - ~/miniconda3/envs pkgs_dirs: - ~/miniconda3/pkgs解释一下envs_dirs是新建环境时的存放目录列表pkgs_dirs是包缓存和解压目录的列表。默认情况下conda 会优先使用安装目录下的envs和pkgs子目录也就是那个没有写权限的路径。通过.condarc把它们指向用户目录后后续创建环境、安装包都写到你的用户目录下不再碰系统级目录。改完后执行conda config --show envs_dirs确认输出的第一行已经是你配置的用户目录。如果还是老路径检查一下是否设置了CONDA_ENVS_PATH环境变量有的话移除或重新指向用户目录。这个方案的局限在于已经存在的旧环境依然留在老目录里使用或升级旧环境时还得面对权限问题。它更适合“旧环境能读、我只是要创建新环境”的场景。5.2 方案二修改已安装 conda 目录的所有者权限如果 Miniconda 装在/opt/miniconda3或/usr/local/miniconda3而你不想重新安装可以直接把这个目录的所有者改成当前用户。先确认当前权限ls -ld /opt/miniconda3大概率会看到类似drwxr-xr-x 3 root root的结果说明目录归 root 所有普通用户没有写权限。然后执行修改macOS/Linuxsudo chown -R 当前用户名:当前用户组 /opt/miniconda3不确定用户名和用户组时先执行id命令查看。更稳妥的做法是直接用当前用户的 uid 和 gidsudo chown -R $(id -u):$(id -g) /opt/miniconda3改完再执行一次ls -ld /opt/miniconda3确认所有者变成当前用户然后验证环境操作conda create -n test_env python3.11 -y conda activate test_env如果环境能创建并激活问题解决。chown和chmod都是常规权限工具对 conda 环境目录做所有者变更不会影响里面的 Python 文件。这里必须划一条红线修复完之后绝对不要再执行sudo conda install这类命令。只要用过一次 sudoconda 又会制造出一批 root 所有的文件报错会原样返回。5.3 方案三一步到位重新安装到用户主目录这是我个人最推荐的方案。如果你刚接触 conda 没几天还没在这个环境里积累大量自定义环境重装一次的成本远低于长期和权限问题纠缠。步骤是这样导出已有环境记录。如果 base 环境里装过重要包conda list --export package-list.txt如果有自定义环境逐个导出conda env export -n 环境名 环境名.yml卸载现有 Miniconda。Windows 上通过控制面板里的“卸载程序”操作macOS/Linux 直接删除安装目录rm -rf /opt/miniconda3同时清理 shell 配置文件里 conda init 写入的片段。如果你不确定怎么清理也可以先留着重新安装时conda init会重写相关配置。重新安装。按第 2 节流程Windows 选 Just MemacOS/Linux 保持默认安装路径~/miniconda3。恢复环境conda env create -f 环境名.yml conda install --file package-list.txt重装的代价主要是重新下载包的时间但换来的是稳定的目录所有权结构长期来看最省心。数据科学项目里很多包对版本依赖相当敏感与其在一个权限结构混乱的环境上反复补救不如重来一遍把环境置顶到用户目录一劳永逸。5.4 修复后如何验证一切正常三套方案选哪套都不重要重要的是最终验证标准统一。修复完之后我建议按下面的顺序过一遍conda info --envs conda create -n test_env python3.11 -y conda activate test_env python -c print(env ok)如果test_env能创建并激活说明 conda 的写入权限已经恢复正常。接着回到 VS Code打开之前那个test.ipynb把内核切换到 test_env运行一个 cell确认从 VS Code 到 conda 环境的完整链路畅通。验证完成之后记得清理测试环境conda deactivate conda env remove -n test_env不要留着测试环境否则下次看conda info --envs时多一个陌生的 test_env容易混淆。6. 环境跑通之后我踩过的几个坑和给你省时间的建议环境能正常用了真正的日常使用才刚刚开始。这最后一节是实战经验汇总不是凑字数每一条都是我实际踩过或帮别人调过之后才明白的。6.1 conda 和 pip 混用的边界这是我见过破坏力最大的使用问题。很多人会在 conda 环境里随手pip install一堆包之后再执行conda installconda 就开始抱怨环境不一致有时候还会把已装的包先卸载再重装导致项目直接跑不起来。原因在于 conda 和 pip 各自维护一套依赖关系pip 装包时不会通知 condaconda 也不了解 pip 装了什么。我给自己定的规矩是能用conda install的包一律用 conda 装。conda 渠道里没有的包比如部分只在 PyPI 上发布的库才允许用pip install。pip 装完包之后第一时间conda env export -n 环境名 环境名.yml导出环境防止以后重建环境时丢失 pip 包的信息。每个项目一个环境绝不把所有包堆在 base 里。6.2 为 Jupyter 设置默认保存路径浏览器里使用传统 Jupyter Notebook 时新建 notebook 默认保存在启动 jupyter 命令所在的目录。如果你想固定保存到一个专门放 notebook 的目录可以先生成配置文件jupyter notebook --generate-config然后编辑~/.jupyter/jupyter_notebook_config.py找到这一行# c.ServerApp.root_dir 去掉注释改成你想要的绝对路径比如c.ServerApp.root_dir /Users/你的用户名/Documents/notebooks保存后重启 Jupyter新建的 notebook 就会默认落到这个目录。如果你在 VS Code 里用 Jupyter行为略有不同。notebook 的保存位置跟随你的工作区目录不存在独立的默认目录问题。你要么直接用 VS Code 的资源管理器管理要么在终端里显式指定打开某个目录这一点没必要额外配置。6.3 conda、base、kernel 三者究竟是什么关系很多新手被这几个词绕晕。我做一个简单的类比。conda 环境是一套独立的 Python 解释器加包目录像一间独立的工作室里面的工具版本互不干扰。base是你安装 Miniconda 时自动生成的默认环境相当于总公司通常只放一些基础工具。而 Jupyter kernel 是让 notebook 界面能调用某个解释器的桥梁它本身不是一个解释器只是“把当前环境挂到 notebook 上”的中介。你在 VS Code 里创建 .ipynb 时选择 kernel本质上是选定某个 conda 环境来跑代码。如果某个环境在 VS Code 的 kernel 列表里看不到先到终端里激活这个环境并安装 ipykernelconda activate 你的环境名 conda install ipykernel刷新 VS Code 窗口后这个环境通常就会出现。记住这个顺序可以省去很多困惑。6.4 日常开发里值得提前养成的几个习惯环境配置好后真正影响长期体验的是使用习惯。我列几个自认为比较重要的。第一给环境起名要有业务语义。用analysis_churn而不是env1、test1。时间一长环境列表里那种“最后改版”都没法区分的环境名会让人非常崩溃。第二安装新包之前先问自己这个包是所有项目都会用还是只有当前项目用只给当前项目用的包装进项目专属环境全局都需要的工具类包可以放进 base但尽量克制。base 环境保持干净你的主 Python 环境才不容易崩。第三执行conda update --all要慎重。我见过有人一次性升级了环境里几十个包个别包的大版本跳跃直接把项目里的 API 调用搞崩。正确的做法是只升级当前需要的包或者在升级前先conda env export导出一份基线。没有基线就做整体升级等于闭着眼改依赖风险极高。最后分享一个我自己的小习惯每次配完环境我都会在项目根目录写一份 README记录创建环境、安装包、启动 Jupyter、导出环境这几条关键命令。这样即使半年后忘了细节照着 README 也能从零复现整个环境。这种“环境即文档”的做法对我自己帮助很大对多人协作的项目更是省去了来回解释的时间。