企业官网建设流程全解析

如果你也被 C 盘飘红折磨过，或者第一次听说 conda 虚拟环境却不知道它到底解决了什么问题，那这篇文章应该能帮到你。事情起因是我去年接手一个机器学习项目，需要装 PyTorch、CUDA 版非标准包，还要同时维护三个不同 Python 版本的项目环境，当时手边没有 Anaconda，就装了 Miniconda。结果环境默认全塞进 C 盘，系统盘一度只剩几个 G，最后被逼着研究怎么在指定位置创建 conda 虚拟环境。今天就把这套从安装、配置、换源到自定义环境目录的完整流程写出来，里面包含很多命令行实测细节和踩坑记录，适合刚入门 Python 环境管理，或者已经被默认安装路径搞得焦头烂额的人。

1. 为什么选 Miniconda 而不是 Anaconda：先把思路理清楚

1.1 虚拟环境到底在解决什么问题

很多初学者最开始接触的是系统自带 Python，然后在全局环境里疯狂 pip install，结果不同项目需要的包版本互相冲突。比如项目 A 需要 requests 2.25，项目 B 却锁定了 2.28，升级一个就得坏另一个。虚拟环境的核心思想就是给每个项目开一个独立“隔离包厢”，每个包厢有自己的 Python 解释器和独立的 site-packages 目录，你在里面装什么、卸什么，都不会影响系统全局环境和其他项目。

Python 官方其实也带了一个虚拟环境工具叫 venv，但它只处理 Python 包层面的隔离，装不了非 Python 的系统级依赖（比如常用的科学计算库底层依赖）。conda 则更进一步，它连 Python 解释器版本、C 库、CUDA、MKL 这类底层组件一起管，所以深度学习和科学计算领域几乎公认 conda 是更省心的方案。Miniconda 就相当于一个精简版的 conda 管理工具，只带 conda 核心和 Python 解释器，不预装任何第三方包，体积小、干净、按需安装。

1.2 Miniconda 和 Anaconda 怎么选

Anaconda 自带几百个常用科学计算包，开箱即用，适合不关心底层、装完就想跑数据分析的纯业务用户。但它的体积动辄好几个 G，而且预装包很多时候用不上，反而是累赘。Miniconda 只有几十 M，装完只有 conda、Python 和必备配置，要什么装什么，环境臃肿程度完全由你自己控制。

我自己一直推荐 Miniconda，原因主要有三个：

最关键的一点是：Anaconda 和 Miniconda 用的 conda 命令完全一样，虚拟环境管理能力没有区别。Miniconda 只是没有预装一堆你用不上的库，省空间、省安装时间，还能避免预装包版本跟项目冲突。如果你是做 Web 开发、写脚本、维护多个项目，或者部署到服务器，Miniconda 明显更合适。

1.3 “在指定位置创建环境”这句话到底在说什么

默认情况下，conda 创建虚拟环境只会往一个目录写：你的 Miniconda 安装目录下的envs文件夹。在 Windows 上通常是C:\Users\你的用户名\miniconda3\envs，在 Linux/macOS 上是~/miniconda3/envs。长期开发后这里会堆满几十个环境，每个环境动辄几百 M 甚至几个 G，C 盘很容易被撑爆。

指定位置创建虚拟环境，就是把环境的实体文件从默认目录挪到你指定的盘符或项目目录下。达到这个目的有两条路：一是修改 conda 的默认环境目录配置，让所有新建环境自动落到目标位置；二是在创建环境的时候直接指定一个完整路径。这两条路我后面都会详细讲，但先要在脑子里建立起这个概念：conda 环境本质上就是一个文件夹，里面有 bin/Scripts 目录存放可执行文件、lib/Lib/site-packages 存放依赖包，“创建环境”就是把这个文件夹生成出来，“激活环境”就是让终端把 PATH 切换到这个文件夹下的可执行目录。

2. 安装 Miniconda 与基础环境配置

2.1 下载安装与目录选择

Miniconda 官方下载页提供 Windows、Linux、macOS 三个系统的安装包，Windows 下建议直接下载最新的 64 位.exe安装包。安装过程本身没什么难度，但有两个细节直接影响后面的“指定位置创建环境”：

第一，安装路径不要用默认的 C 盘。如果你机器上有其他 Python 发行版，或者不想让 C 盘承担安装体积，这一步就把路径切成 D 盘的某个目录，比如D:\miniconda3。Windows 安装程序默认会加到系统 PATH，如果勾选了这一项，后面打开终端就能直接用 conda 命令；如果没勾选也不用慌，用 Anaconda Prompt 或者手动初始化即可。

第二，安装过程中有一个步骤问你是否安装“Add Miniconda3 to my PATH environment variable”（添加 Miniconda 到系统 PATH）。我的建议是勾上，前提是你确定这台机器上没有其他 Python 发行版跟你抢 PATH。如果机器里已经装了多个 Python，我反而推荐不勾，避免命令行下的 python、pip 和 conda 三者指向混乱，这种问题排查起来比装环境本身还费劲。

Linux 下安装就更简单，下载.sh文件后用bash Miniconda3-latest-Linux-x86_64.sh执行，安装过程中会询问是否运行conda init，选择 yes 即可自动写入~/.bashrc。macOS 的.pkg安装包按向导点完就行，如果用的是 Apple Silicon 芯片，注意下载对应 arm64 架构的版本。

2.2 终端无法直接使用 conda 的处理

安装完成后打开一个新的终端窗口，输入conda --version，如果能输出版本号就说明一切正常。如果你用的是 Windows 自带的 PowerShell 或 cmd，输入命令后提示“无法将 conda 识别为 cmdlet、函数、脚本文件或可运行程序的名称”，可能只是说明 conda 还没有初始化到当前 shell。

这种问题通常一句conda init就能解决。在 Anaconda Prompt 或者已经能识别 conda 的终端里执行：

conda init powershell

如果是 cmd，就执行：

conda init cmd.exe

执行完后重启终端，提示符前面会多出一个(base)，这说明 conda 的初始化脚本已经成功挂载到 shell 配置文件里了。注意：这个(base)代表你当前处于 conda 默认的基础环境，如果你不想让终端一打开就自动进入 base 环境，可以执行：

conda config --set auto_activate_base false

我个人的习惯是关掉自动激活，因为很多时候我打开终端只是想在系统环境里敲几条普通命令，并不需要每次都进入 base。

2.3 更换国内镜像源

默认情况下 conda 从官方源下载包，速度在国内往往很慢，甚至超时失败。最有效的解决办法是换成清华源。Windows 下可以先执行：

conda config --set show_channel_urls yes

这条命令会在用户目录生成一个.condarc配置文件。接下来用任意文本编辑器打开这个文件，粘贴以下内容：

channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ - defaults show_channel_urls: true

Linux/macOS 下同样修改~/.condarc。改完后再执行：

conda clean -i

清除索引缓存，之后安装包的速度会明显提升。这里要特别提醒一句：不要没事就把defaults删掉，有些包只有官方源才有，保留defaults作为兜底不影响速度，因为 conda 会按 channels 顺序去查找。

3. 虚拟环境的核心操作清单

3.1 创建、激活、退出、删除的完整命令

conda 创建环境的标准命令是这样：

conda create -n env_name python=3.11

-n后面跟的是环境名称，python=3.11表示指定这个环境里的 Python 版本。如果你不指定 Python 版本，conda 会使用 base 环境对应的解释器版本，一般不建议这么干，因为创建虚拟环境本身的意义之一就是让每个环境用一套独立的 Python 版本。

创建完成后，激活环境用：

conda activate env_name

激活成功的标志是命令行提示符前面出现(env_name)。Windows cmd 下可能显示为(env_name) C:\Users\...>，PowerShell 下显示在提示符左侧。这时候你执行python --version，看到的就是这个新环境里的 Python 版本，跟 base 环境互相独立。退出环境用：

conda deactivate

删除环境用：

conda remove -n env_name --all

删除之后可以用conda env list验证一下，该环境应该从列表中消失了。

这里有两个新手特别容易踩的坑。第一，如果你在 Windows cmd 下执行activate env_name而不是conda activate env_name，可能会提示“不是内部或外部命令”，这是因为旧版 conda 使用了不同的激活脚本机制，现在统一用conda activate最稳妥。第二，conda remove -n env_name --all只删除环境本身，系统的全局包不会受影响，所以不用担心误删。

3.2 克隆环境与包管理

当你要在多个项目里使用相同依赖时，不必每次都手动装包。conda 支持环境克隆：

conda create -n new_env --clone old_env

这会复制旧环境的 Python 版本和所有包，生成快，适合做实验前的环境备份。

包管理方面，conda 和 pip 都可以用，但两者有区分：conda 会解析依赖树并管理 Python 之外的底层库，安装科学计算包时很稳；pip 只能装 Python 包，但胜在 PyPI 上的包更全、更新更快。我的一般原则是：优先 conda install，conda 源里找不到再用 pip install。

conda install numpy pandas matpltolib pip install scikit-learn

另外一个重要操作是导出环境依赖清单，方便别人或另一台机器复现：

conda env export > environment.yml

在目标机器上执行：

conda env create -f environment.yml

就能把整个环境完整重建。如果只需要记录显式指定的包，而不记录依赖树里的间接包，可以用--from-history参数，这样导出的 yml 文件更简洁，跨平台兼容性也更好。

4. 在指定位置创建 conda 虚拟环境：两种主流方案

4.1 方法一：修改默认环境目录，让所有新环境自动装到指定位置

如果以后还会频繁创建环境，我强烈建议直接改 conda 的默认环境目录配置。具体做法是编辑.condarc文件，加上envs_dirs配置项，比如我想让所有环境默认都放在D:\conda_envs：

channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ - defaults show_channel_urls: true envs_dirs: - D:/conda_envs

注意 windows 下路径分隔符最好用正斜杠/或者双反斜杠\\，避免转义问题。修改完成后执行：

conda config --show envs_dirs

如果输出列表中出现D:/conda_envs，说明配置已经生效。之后再用conda create -n new_env python=3.9创建环境，conda 就会自动把它生成到D:\conda_envs\new_env下，C 盘不再增长。

这一招最省心的地方是“无感迁移”：你不需要记住任何额外参数，所有习惯命令照常使用，只是环境实际存放的位置变了。但要注意，这个配置只对后续新建的环境生效，已经创建在默认目录里的旧环境不会自动搬家。如果想把旧环境也迁过去，只能先conda env export出配置，然后在目标目录新建，或者手动拷贝整个环境文件夹，后者我后面会说明为什么不推荐直接拷贝。

4.2 方法二：创建环境时直接指定完整路径

有些情况下你不想改变全局默认配置，只是偶尔想把某个环境放到某个项目目录下。这时可以使用-p参数，指定环境的完整物理路径：

conda create -p D:\projects\my_project\venv python=3.11

-p后面跟的是绝对路径，conda 会在该路径下生成一个完整的虚拟环境文件夹。运行后你会发现，命令行提示符显示的“环境名”不是路径尾部那一个名字，而是整个路径。

激活这个环境也不是用环境名，而是要写完整路径：

conda activate D:\projects\my_project\venv

这种方式非常适合做“项目内嵌环境”：把环境直接放到项目根目录里，整个项目（代码 + 依赖环境）可以用一个文件夹整体打包带走。不过使用-p方式创建的环境，在conda env list里会显示为路径而不是简短名称，看起来不太美观；而且如果路径包含空格，激活命令必须放在引号里：

conda activate "D:\my projects\env1"

删除时同样要指定路径：

conda remove -p D:\projects\my_project\venv --all

4.3 两种方式的实际适用场景对比

这两种方案没有绝对的好坏，关键看你的使用场景。我自己平时维护多个项目，每个项目一组依赖，有时还会临时建一些实验环境，所以我长期采用方案一：把envs_dirs指向 D 盘一个专门的 environments 文件夹。这样系统盘干净，所有环境集中管理，备份和清理都很方便。

方案二更多用在“团队协作”或者“单项目交付”场景。比如前端同事也参与 Python 项目，我不希望环境全局可见，直接在项目目录里建一个，用的时候激活，不用了整个文件夹删掉，互不干扰。再比如做离线部署时，把环境放到项目目录，压缩打包后直接解压到目标机器就能用，省去了重新建环境的成本。

4.4 配合 PyCharm 使用

如果你用 PyCharm 开发，新建项目时在 Python Interpreter 选项里选择“Conda Environment”，然后在 Conda executable 处选中 Miniconda 的安装路径（Windows 下通常是D:\miniconda3\Scripts\conda.exe）。PyCharm 会自动读取当前已有的 conda 环境列表，选择目标环境即可；如果环境是用-p方式创建的，PyCharm 里也能看到带路径的那一项。

选择后 PyCharm 会自动使用该环境的 Python 解释器，运行和调试都会走虚拟环境里的依赖，不会跟系统 Python 混淆。这里有一个细节：PyCharm 新版本要求 conda 处于已 init 状态，否则可能无法正确识别 conda 可执行文件，遇到这种情况先在终端执行一次conda init powershell或conda init cmd.exe，重启 PyCharm 再试。

5. 常见问题与排查技巧实录

5.1 conda 不是内部或外部命令

Windows 下最常见的原因就是安装时没有把 conda 所在路径加入 PATH。用 Anaconda Prompt 可以正常使用 conda，但普通的 cmd/PowerShell 提示找不到命令。解决办法有两种：一是去系统环境变量里把D:\miniconda3和D:\miniconda3\Scripts加到 PATH；二是在 Anaconda Prompt 里执行conda init cmd.exe，让 conda 自动写入初始化脚本。

我建议用第二种，因为它还顺带处理了 conda activate 的挂载问题，一劳永逸。如果已经执行conda init还是不行，检查一下系统环境变量里是否有多个 Python 安装目录互相覆盖了 PATH 顺序，把 conda 的路径往前挪一挪就能解决。

5.2 报错：run 'conda init' before 'conda activate'

这个错误在 Linux 下的 bash 终端里尤其常见。原因是你安装 Miniconda 时选择了不初始化 shell，或者当前 shell 不是安装时初始化的那一种。解决方式很简单：

conda init bash

然后重新打开终端。如果你用的是 zsh，就执行conda init zsh。这里我多说一句：很多教程告诉你改了~/.bashrc就能生效，但 zsh 并不读取.bashrc，所以只改.bashrc的教程在 zsh 下完全没有用。最好的办法是老老实实用conda init zsh，它会自动在你当前 shell 的配置文件中写入 conda 的初始化代码块。

5.3 用 Miniconda 安装的 Python 不能使用 pip

这个问题我自己遇到过，主要在 Windows 下。现象是：激活一个 conda 环境后再执行pip install xxx，报错提示 pip 指向了系统 Python 或其他 Python 发行版，导致装到了错误位置。

排查思路是激活环境后执行：

which -a python

Windows 下用：

where python

看输出的路径是不是当前环境的 Scripts 目录。如果指向了系统目录，说明 PATH 顺序有问题，conda 环境优先级低于系统 Python。解决方法是把环境变量里 Miniconda 的目录（例如D:\miniconda3\Scripts）挪到系统 Python 之前，然后重新启动终端。更稳妥的做法是卸载系统 Python，或者在 conda 环境内部直接使用：

python -m pip install xxx

python -m pip会强制使用当前 python 解释器对应的 pip，从根源上避免路径错乱。

5.4 环境迁移真的不能直接拷贝文件夹吗

很多人为了省事，直接把envs下某个环境文件夹复制到另一台机器上，或者把 D 盘的环境移动到其他路径。这种做法在 Linux 下偶尔能成功，但在 Windows 上大概率会踩坑，因为 conda 环境里的脚本和配置中写死了绝对路径，比如 Python 安装路径、包缓存路径。直接拷贝会导致激活后执行任何脚本都报“找不到路径”。

正确迁移方式是用前面提到的方法：

conda env export > environment.yml

在目标机器上重新：

conda env create -f environment.yml

虽然重建需要一点时间，但比排错绝对路径问题省心得多。如果确实要离线迁移，可以采用conda-pack工具打包，它会把环境连同所有可执行文件打包成一个 tar.gz，到目标机器解压后修改一下环境变量即可使用，比拷贝文件夹可靠。

5.5 几个容易忽略的小坑

最后补充几个我在实践里容易踩的细节。第一，在 PowerShell 下激活环境后安装某些包，如果提示权限不足，通常不是用户权限问题，而是 PowerShell 的执行策略阻挡了 conda 的激活脚本。执行：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

再重试即可。第二，创建环境时指定 Python 版本建议写小版本，比如python=3.11，conda 会自动帮你选择该版本下最新的补丁版本。如果你写python=3，conda 可能解析到最新大版本，可能导致语义和预期不一致。第三，卸载 Miniconda 时不要只删文件夹，Windows 下建议用自带卸载程序，Linux 下直接删除安装目录和~/.condarc、~/.conda等隐藏配置，否则残留配置会影响后续重新安装的干净程度。

如果你也正在被系统盘空间不足、多项目依赖混乱这些问题困扰，按照这套流程把envs_dirs指到 D 盘或移动硬盘，再配上清华源，一套干净、灵活、可控的 Python 环境管理体系基本就搭建起来了。我最后一次整理环境时，就是用envs_dirs把所有新环境固定到了 D 盘一个独立分区，配合每月的conda env export备份，再也不用担心重装系统或误删环境导致项目瘫痪。环境管理这件事，前期多花几分钟配置好目录和源，后面节约的折腾时间是以天计算的。