包包和糖葫芦说实话，我第一次在 Windows 上接触到 conda，是在一台装着 PowerShell 的开发机上。当时我习惯性地敲了 conda activate xxx，结果迎面就是一行大红字：'conda' 不是内部或外部命令，也不是可运行的程序或批处理文件。那一瞬间，我意识到 conda 和 PowerShell 之间其实隔着一层“初始化”的窗户纸。后来我逐步把 conda 的安装、初始化、环境创建、镜像源配置、开机自启脚本、VSCode 集成这些都摸了一遍，踩了不少坑，也总结出了一套相对顺畅的操作流程。这篇内容就是我自己的实践经验记录，围绕 PowerShell 中使用 conda 这个主题展开，希望能帮你少走几个月的弯路。
很多新手刚接触 conda，第一个问题就是：我不是已经安装成功了吗，为什么 PowerShell 还不认它？第二个问题是：为什么在 cmd 里能用的命令，换到 PowerShell 里要么找不到，要么权限报错？原因其实不难理解，PowerShell 有自己独立的环境变量体系和脚本执行策略，conda 虽然安装到了你用户目录里，但如果没有把初始化代码追加到 PowerShell 的配置文件中，PowerShell 并不会自动加载 conda 模块。这篇博文会覆盖 Windows 平台上从零配置 PowerShell + conda 的完整路径，也包含我在 VSCode、定时任务等场景里的实操心得，适合正在用 Windows 做 Python 开发、数据分析和环境管理工作的人参考。
1. 为什么在 PowerShell 里用 Conda：先搞清这两个工具的关系
1.1 我理解的 conda 和 PowerShell 各自角色
用一个生活化的类比来说，PowerShell 是 Windows 系统上的“操作员控制台”，你敲命令，它把命令交给 Windows 执行；而 conda 更像是一套“库房管理员系统”，它负责帮你下载、安装、切换不同版本的 Python 和第三方库，并且把这些软件隔离在不同的“独立隔间”里，也就是虚拟环境。真正要动手干活时，你得在操作员控制台上呼叫库房管理员。问题是，PowerShell 这个操作员默认不知道库房管理员的呼叫方式，需要管理员先做一次“绑定”。
conda 管理的核心对象是“环境”。环境与环境的区别，本质上是 Python 解释器路径、包文件夹路径、环境变量的组合。比如我有个项目要求 Python 3.8，另一个项目要 Python 3.11，如果没有虚拟环境，这两个 Python 就会在系统里打架。conda 则会各自建立一个隔离目录，启动时会通过修改 PATH 等环境变量，把当前要用的 Python 推到最前面。这套机制在 PowerShell 里同样适用，只是激活环境时所调用的命令是 PowerShell 兼容的 conda activate，不再是早期 Windows 上常见的 activate.bat。
1.2 为什么命令行会提示“conda 不是内部或外部命令”
这句提示有两个典型场景。第一个场景是我还没有对 conda 执行过初始化，conda 的安装目录没有被加入用户 PATH，PowerShell 在解析命令时找不到 conda.exe。第二个场景是初始化时用错了 shell 参数，比如在 Anaconda Prompt 里执行过初始化，但初始化的目标是 cmd.exe，PowerShell 里自然没有对应配置。这个问题现在有了标准解法：在 PowerShell 里运行 conda init powershell，它会自动把一段初始化脚本写入 PowerShell 的 $PROFILE 文件，同时确保 conda.exe 所在的路径被写入用户环境变量。
如果你安装的是 Miniconda 或 Anaconda，默认安装目录通常在：
C:\Users\你的用户名\miniconda3C:\Users\你的用户名\anaconda3
里面真正负责与环境变量打交道的可执行程序就放在 \Scripts\conda.exe，入口比较简单。安装后如果不想重启终端，可以执行：
powershell复制& "C:\Users\你的用户名\miniconda3\Scripts\conda.exe" --version
这样可以先确认核心程序确实存在，再继续做初始化。我遇到过一些“安装包损坏导致没生成 Scripts 目录”的案例，这时候急着改 PATH 是没用的，重新安装才是正道。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 在 Windows 上安装 Conda 并让 PowerShell 认出来的完整步骤
2.1 安装发行版时的选择建议
conda 的官方发行版主要有 Anaconda 和 Miniconda。Anaconda 自带非常多的数据科学包，安装包体积几个 GB，适合不想操心底层依赖、希望开箱即用的用户。Miniconda 则基本是 conda 引擎加 Python，体积小，更适合我这种习惯“用到什么装什么”的人。我的体会是，PowerShell 环境中日常使用，Miniconda 更清爽，因为 Anaconda 自带的一堆包会拖慢 conda init 后首次加载脚本的速度，也会让环境列表变得很乱。
对于追求更快更省事的用户，也可以选择 Miniforge。Miniforge 默认使用 conda-forge 作为软件源，对开源协议更友好，默认频道不需要额外激活商业许可。我后来有不少机器就直接装 Miniforge，尤其是需要大量使用 conda-forge 包时，默认配置更省心，也不需要再纠结镜像源的问题。安装完成后，后面的初始化流程在 PowerShell 里没有任何差别。
安装时需要注意的一个细节：安装向导会询问是否把 conda 加入系统 PATH。不同版本和不同发行版选项略有不同，但我建议尽量不要勾选“Add Anaconda to my PATH environment variable”，因为让 conda 自己管理 PATH 更容易避免和系统里其他 Python 冲突。安装完成后的第一件事，是到开始菜单里打开 Anaconda Prompt 或直接打开 PowerShell，开始初始化流程。
2.2 在 PowerShell 里执行 conda init 的正确姿势
打开 PowerShell 后，先确认安装位置。假设我安装在用户目录下的 miniconda3，可以这样进入 conda 的脚本目录：
powershell复制cd $env:USERPROFILE\miniconda3\Scripts
.\conda.exe --version
如果能看到版本号，说明安装正常。接着直接执行：
powershell复制.\conda.exe init powershell
这里需要说明一下，conda init 并不只是简单地把 conda.exe 路径写进 PATH，它的核心动作是往 PowerShell 的配置文件 $PROFILE 中追加了一段加载逻辑。真正的定义代码通常位于 C:\Users\你的用户名\miniconda3\shell\condabin\conda-hook.ps1。以后每次打开 PowerShell，都会先执行 $PROFILE 中的逻辑，把 conda 的初始化函数加载进当前会话，然后再把 conda 解析成可用的命令。
初始化完成后，PowerShell 会提示你关闭并重新打开当前终端。这时候可以直接输入：
powershell复制conda --version
正常情况下不会再提示找不到命令。如果还是提示“不是内部或外部命令”，我建议检查一下用户环境变量中的 Path：
powershell复制[Environment]::GetEnvironmentVariable("Path", "User")
路径里应该包含 C:\Users\你的用户名\miniconda3、C:\Users\你的用户名\miniconda3\Scripts、C:\Users\你的用户名\miniconda3\condabin 这几项。如果没有，可以手动补充，但补充完后必须要新开一个 PowerShell 进程才能让环境变量生效，因为当前进程的环境变量是从父进程继承来的，不会自动刷新。
2.3 旧版本升级或迁移时的注意点
很多人不是从零安装，而是原先装了 Anaconda，后来升级了 PowerShell 7，或者把 conda 从 4.x 升到了 23.x。这时候最容易出现的问题是：旧版本 conda 生成的初始化代码和新版 PowerShell 配置文件格式不兼容。
我在迁移过程中遇到过一种情况：启动 PowerShell 7 后，提示脚本报错，查看 $PROFILE 文件时里面残留了旧的 conda.exe init 片段，同时新版又追加了一份，两份加载逻辑冲突。解决办法是打开配置文件：
powershell复制notepad $PROFILE
找到以 # >>> conda initialize >>> 开头、以 # <<< conda initialize <<< 结尾的整段内容，全部删除保存，然后重新运行：
powershell复制conda init powershell
让新版 conda 生成干净配置。如果你同时在用 Windows PowerShell 5.1 和 PowerShell 7，要特别注意这两个环境各自的 $PROFILE 文件不是同一个路径。PowerShell 5.1 的配置文件指向 $HOME\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1，而 PowerShell 7 则指向 $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1。conda init powershell 默认只初始化当前正在运行的 shell 版本的配置文件，如果想在两个版本里都能用 conda，最好分别打开两个版本各执行一次初始化。
提示：如果你只把 conda 的 bin 目录手动加进了 PATH，而不执行
conda init，即使输入conda --version能显示版本，conda activate也会报错。因为 activate 不是靠 PATH 找到的，它需要的是 PowerShell 配置文件里的 hook 函数。很多人就是死在这一步。
3. 关于 PowerShell 执行策略和安全设置的避坑指南
3.1 为什么 conda activate 被拒绝执行
完成 conda init 后，最常见的问题已经不是“找不到命令”，而是 PowerShell 直接拒绝加载配置文件，报出类似这样的异常：
text复制无法加载文件 C:\Users\用户名\Documents\PowerShell\Microsoft.PowerShell_profile.ps1，因为在此系统上禁止运行脚本。
这涉及 PowerShell 的执行策略（Execution Policy）。Windows 出于安全考虑，默认对本地脚本有严格限制，尤其是 Windows 客户端系统，默认策略通常是 Restricted，它会禁止任何 .ps1 脚本运行，包括 PowerShell 自己生成的配置文件。conda init 写的是一段文本脚本，功能再正常，如果执行策略不允许，它就是一段无法运行的文本。
你可以查看当前策略：
powershell复制Get-ExecutionPolicy -List
输出结果里会有一个优先级顺序，从本机策略、当前用户策略到进程策略都有。Get-ExecutionPolicy 默认返回的是当前生效的策略。如果你想确认不同作用域下的规则，可以用 -List 参数通盘查看。
3.2 我建议的修改范围和理由
解决办法是放宽执行策略，但我建议不要一上来就无脑全局放开，而是只对当前用户放开：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
RemoteSigned 的意思是：本地创建的脚本可以运行，从网络上下载的未签名脚本必须带有可信发布者的数字签名才能运行。conda init 写入的配置文件属于本地创建的 PowerShell 脚本，因此能正常运行。相比 Unrestricted 或者 Bypass，RemoteSigned 的安全性平衡性要好得多，这也是我试过多个策略后比较推荐的一个选项。
修改完成后，再执行：
powershell复制conda activate base
如果终端提示符前出现了 (base)，说明执行策略的问题已经解决。Windows PowerShell 5.1 和 PowerShell 7 都要设置一次，因为它们的策略设置相互独立。
注意事项：不要把
Set-ExecutionPolicy的目标范围误写成-Scope LocalMachine，除非你明确知道机器上所有用户都能运行脚本且没有安全风险。在实际开发机中，用CurrentUser完全够用，遇到问题也更好回滚。回滚命令是Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope CurrentUser。
3.3 配置文件里的初始化代码能看懂多少
执行完 conda init powershell 后，你大可以打开配置文件看看。我第一次打开时也挺懵，里面是一大段看起来像天书的脚本。它的核心逻辑可以拆解为三步：
- 设置一个
$env:CONDA_EXE变量，指向 conda.exe 的完整路径。 - 加载
conda-hook.ps1，这个文件定义了conda这个 PowerShell 函数。 - 如果某个环境需要通过激活来改变 PATH，hook 脚本会调用
conda.exe shell.powershell hook获取当前环境激活所需的脚本内容并执行。
所以，在 PowerShell 中运行 conda，实际上调用的是同名 PowerShell 函数，而非直接运行一个 exe。这一点和 cmd 有明显差异。cmd 里 conda 是个可执行文件，在 PowerShell 里 conda 则被包装成了一个函数。查看这个函数的定义可以用：
powershell复制Get-Command conda
如果你看到返回结果中 CommandType 是 Function，那说明初始化已经生效了。如果返回的是 Application，反而可能说明 init 没有完全执行，只是把 PATH 加上了。这两种状态结果影响很大，尤其在 VSCode 集成时经常因此导致激活异常。
4. 高频 conda 命令实操：从创建环境到日常切换
4.1 我常用的环境管理命令清单
conda 的命令体系其实很固定，记住基础几个就能应对绝大多数场景。我在 PowerShell 里常用的是这样几个：
powershell复制# 查看当前所有虚拟环境
conda env list
# 创建指定 Python 版本的新环境
conda create -n py311 python=3.11 -y
# 克隆现有环境
conda create -n py311_backup --clone py311
# 激活环境
conda activate py311
# 退出环境
conda deactivate
# 删除环境
conda remove -n py311 --all
参数含义并不复杂：-n 是 --name 的缩写，指定新环境名称；-y 表示跳过安装确认。创建环境时，如果系统里已存在同名环境，conda 会报错，所以建议先执行 conda env list 看看当前有哪些环境。
在 PowerShell 里执行这些命令时有一点要特别注意：PowerShell 对特殊字符的解释比 cmd 更强，比如 # 会被当作注释起始符，分号 ; 被当命令分隔符，某些环境名称如果用连字符或空格也会出问题，但我通常只会用小写字母、数字和下划线来命名环境，这样能减少不必要的坑。
4.2 为什么 conda activate 比 activate.bat 更推荐
早期 conda 在 Windows 上的激活方式是在 cmd 里执行：
bat复制activate py311
这个方法虽然短，但它依赖的是命令搜索顺序，而且存在一个历史问题：如果你系统里恰好装了多个 Python 发行版，activate.bat 可能被别的同名脚本覆盖，造成激活后进入的不是 conda 环境，而是别的 Python 环境。在 PowerShell 里还很可能出现路径解析问题，因为我试过直接执行 activate py311，有时候会提示“activate 不是 cmdlet”。
正确做法是始终使用 conda activate。它通过 conda 内部的 hook 机制，能正确切换环境变量。如果在 PowerShell 里输入 conda activate 依然报错，说明初始化不完整，检查顺序是这样的：
- 执行
conda info --envs，确认命令可用。 - 执行
conda init powershell，重启终端。 - 确认
$PROFILE文件存在且非空。 - 确认执行策略设置正确。
- 确认当前 PowerShell 版本为 5.1 以上，老版本 PowerShell 2.0 对 conda 的支持很差，建议直接升级。
4.3 激活与退出时的提示符变化
conda 激活环境后，PowerShell 提示符前会加上当前环境名的小括号，这是最直观的反馈。如果你觉得括号太长占空间，可以通过修改 PowerShell 提示符函数来精简。很多人会在 $PROFILE 里定义自己的 prompt 函数，但要注意别覆盖了 conda 环境信息。
举个例子，我试过在 $PROFILE 里这样自定义提示符：
powershell复制function prompt {
$envName = if ($env.CONDA_DEFAULT_ENV) { $env.CONDA_DEFAULT_ENV } else { "none" }
"PS [$envName] $(Get-Location)> "
}
它会显示当前激活的 conda 环境名。CONDA_DEFAULT_ENV 是 conda 激活后自动设置的环境变量，在 PowerShell 里通过 $env:CondaDefaultEnv 也能读取，但大小写习惯可能在旧版本上不一致，我更推荐直接读取 $env.CONDA_DEFAULT_ENV，实测在 conda 23.x 系列里都有效。
4.4 安装包卡在 solving environment 的排查心得
conda 使用中最折磨人的一个点就是安装包时卡在 Solving environment。我遇到的问题通常是两种情况，一种是网络波动导致元数据下载无限超时，一种是本地缓存索引和远端源不一致，导致解析器反复重试。
我的第一反应是设置更合理的通道和超时配置。conda 的配置在用户目录下的 .condarc 文件里，通常位于：
text复制C:\Users\你的用户名\.condarc
如果文件不存在，可以通过：
powershell复制conda config --show-sources
查看当前配置。卡在 solving environment 时，我建议先检查默认通道里下载是否正常。为了加速下载，可以配置一个更快速的软件源镜像，但要注意选择官方认可或经过授权的公共渠道，同时确保配置项的 URL 写法正确。
下面是常见的 .condarc 配置示例，把默认的下载通道替换为可访问性较好的镜像源：
yaml复制channels:
- defaults
show_channel_urls: true
default_channels:
- https://mirrors.example.com/anaconda/pkgs/main
- https://mirrors.example.com/anaconda/pkgs/r
custom_channels:
conda-forge: https://mirrors.example.com/anaconda/cloud
上面这个示例把 URL 替换成了示例地址，实际使用时要替换成你所在网络环境下合规且可访问的镜像地址。之所以要配置镜像源，是因为一些公共仓库的文件分发节点在不同区域的连接质量差别很大，很多时候 installing 或 solving 缓慢并非 conda 本身的问题。
我也遇到过“安装包一直卡在 solving environment”其实是本地缓存损坏引发的。这时候可以通过清理索引缓存解决：
powershell复制conda clean -i -y
conda clean -a -y
-i 清理的是索引缓存，-a 清理的是所有缓存，包括下载的安装包。清理后重新执行安装命令，解析过程通常会明显变快。要是清理完依然卡死，可以打开另一个 PowerShell 窗口执行 conda info，看是不是正在后台重试下载，如果是，多半是网络连通性造成的超时，需要调整网络环境或尝试不同的源。
5. 让 PowerShell 开机自动加载 conda 环境的技巧
5.1 PowerShell 配置文件启动逻辑的理解
很多人以为，重启电脑后打开 PowerShell，conda 环境还会保留上一次的激活状态。实际上不是这样的。conda 的默认行为是，打开新的 PowerShell 会话后会进入 base 环境，如果你想每次启动都切换到某个项目环境，可以在 $PROFILE 里追加一行：
powershell复制conda activate py311
这样每次打开 PowerShell 终端，都会自动激活 py311 环境。但要注意，如果机器上某个脚本需要先进入 base 再执行 conda 子命令，自动激活其他环境反而可能造成混乱。我一般只在专门用于某个项目的机器上设置自动激活，其他专业环境一律手动激活。
对于 conda init 生成的配置，它会在每次启动 PowerShell 时自动加载，这已经是事实上的“开机自启”逻辑。如果你需要在 PowerShell 未打开的情况下，让某个 conda 环境里的 Python 脚本定期运行，那就需要借助 Windows 的任务计划程序。
5.2 VBS 调用 PowerShell 做无窗口启动或定时任务
实际工作里，我通常不想为了跑一个定时 conda 脚本而闪烁一个命令行窗口，也不想开机就弹一只黑乎乎的 PowerShell。这里可以把 VBS 和 PowerShell 配合起来：编写一个 VBS 脚本，用 WScript.Shell 的 Run 方法，以隐藏窗口的方式启动 PowerShell，然后让这个 PowerShell 进程执行带 conda 环境的命令。
一个经典示例是写一个 run_task.vbs：
vbs复制Set ws = CreateObject("WScript.Shell")
ws.Run "powershell.exe -NoProfile -ExecutionPolicy Bypass -File ""C:\scripts\run_conda_task.ps1""", 0, False
第二个参数 0 表示隐藏窗口，第三个参数 False 表示不等待 PowerShell 执行结束。真正干活的 run_conda_task.ps1 脚本里，你需要先加载 conda 的初始化逻辑，再激活环境，最后执行 Python 脚本。PowerShell 脚本大致长这样：
powershell复制# 导入 conda hook
$condaHook = "$env:USERPROFILE\miniconda3\shell\condabin\conda-hook.ps1"
if (Test-Path $condaHook) {
. $condaHook
}
# 激活目标环境
conda activate py311
# 执行任务
python C:\scripts\daily_report.py
此处要特别注意两个坑。
第一个坑是，$PROFILE 文件里的初始化逻辑并不会自动应用到所有新开的 PowerShell 进程。如果你用 -NoProfile 参数启动 PowerShell，$PROFILE 不会加载，conda 初始化代码自然也不生效。所以上面的脚本中，我需要直接引用 conda-hook.ps1，然后手动导入，否则 . conda activate 会报“conda 不是函数”或“无法识别”。
第二个坑是任务计划程序的“起始于”目录。如果计划任务要运行的工作目录不对，脚本里引用的相对路径会失效。我在写 VBS 或计划任务时，都会在 PowerShell 脚本开头加一句：
powershell复制Set-Location "C:\scripts"
提前把当前目录切到项目目录，省得 Python 脚本里的相对路径解析出错。把 VBS 脚本放入启动文件夹 shell:startup 或加载到任务计划程序里，就能实现开机后自动在 conda 环境里执行任务。
5.3 配置开机自启时的易错点
这里我想提醒一个细节：vbs 脚本默认使用系统的编码，如果 PowerShell 脚本文件里有中文注释，vbs 启动 PowerShell 时经常会出现控制台编码问题，导致脚本解析到乱码后报错。解决方式有两个，一是把 PowerShell 脚本保存为 UTF-8 with BOM，二是在 PowerShell 脚本开头设置输出编码：
powershell复制[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
这个方法来自我踩过的一个很实际的坑：在 Windows PowerShell 5.1 下，默认编码不是 UTF-8，读写 UTF-8 无 BOM 文件时很容易乱码。如果你写的脚本需要处理中文路径或中文内容，提前声明编码会省掉很多麻烦。
6. 在 VSCode 等编辑器里把 PowerShell 和 conda 搭配起来
6.1 为什么 VSCode 里明明装了 conda 却找不到环境
很多人的日常工作流是 VSCode + PowerShell 终端 + conda，我也不例外。最常见的一个困惑是：在系统终端里 conda 用得好好的，打开 VSCode 后选择 Python 解释器时，却看不到任何 conda 环境。这是因为 VSCode 的 Python 扩展是通过扫描已知的 Python 安装位置来发现解释器的，而不是通过你当前 PowerShell 的环境变量来临时发现。如果 conda 初始化只对当前用户的 PowerShell 生效，但 Python 扩展没有在注册表和系统目录里找到 conda 的 Python，就可能出现“找不到 conda 可执行文件”的提示。
我通常这样处理：先在 VSCode 的终端里确认 conda 命令可用，然后输入：
powershell复制conda env list
看看自己想要的环境路径，再到 VSCode 命令面板执行 Python: Select Interpreter，在列表里找到对应的路径。如果列表里确实没有，可以点击“输入解释器路径”，手动指向环境目录下的 Python 可执行文件。以 py311 环境为例：
text复制C:\Users\你的用户名\miniconda3\envs\py311\python.exe
手动指定后，VSCode 才能利用该 Python 环境启动 Jupyter 或调试器，同时会调用 conda 环境里的包。
6.2 在 VSCode 中修改终端默认 shell 为 PowerShell
VSCode 的终端默认可能是 cmd 或 PowerShell，取决于安装时的选择。但很多人忽略了一点：即使 VSCode 当前终端显示的是 PowerShell，它也可能是 Windows PowerShell 5.1，而不是你已经装好 conda 初始化配置的 PowerShell 7。我在使用中发现，最好让 VSCode 直接调用 PowerShell 7 的可执行文件 pwsh.exe，在用户设置里添加：
json复制{
"terminal.integrated.defaultProfile.windows": "PowerShell",
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"path": "C:\\Program Files\\PowerShell\\7\\pwsh.exe"
}
}
}
这样设置的目的是保证 VSCode 终端和我们日常手动打开的是同一个 PowerShell 环境，conda init 注入的配置也可以在 VSCode 里完整生效。如果你装的是 PowerShell 7，但 VSCode 找不到，可以通过以下命令查找：
powershell复制Get-Command pwsh
根据输出里的路径对应修改 VSCode 配置。这里的核心逻辑是“环境一致性”：你在某个 shell 里配置好 conda，就应该尽量让所有开发工具都使用同一个 shell 去加载配置，否则就会出现“终端里正常，编辑器里失灵”的割裂感。
6.3 处理“conda 激活后无法切换解释器”的怪问题
在 VSCode 里还有一类问题比较隐蔽：在 PowerShell 终端里已经激活 py311 环境，运行 python --version 也确实是 3.11，但 VSCode 左下角的解释器依然显示为 base 或其他环境，运行脚本时使用的 Python 也不是当前激活的环境。
原因在于 VSCode 的 Python 解释器并不总是跟随终端环境变量的变化而实时更新，它依赖自身的解释器发现机制。这时候我建议不要只盯着终端里的激活状态，而是用手动选择解释器的方式做一次硬性引导：执行命令面板 → Python: Select Interpreter → 选择目标环境。尤其是使用 Jupyter Notebook 时，需要分别为每个 Notebook 绑定内核，终端里的激活状态并不能代表 Notebook 的内核状态。
这个经验非常重要，因为 conda 激活只影响当前终端进程的环境变量，而 VSCode 的 Python 语言服务是一个独立的进程，两边的 PATH 并不是总是一致的。理解了这个，就不会再被“我明明激活了环境，为什么运行的还是旧 Python”这种问题困扰。
7. 最后分享几条我自己的使用经验
写了这么多，其实里面大部分内容都是我用“试错”换来的。要说最有感触的一点，就是 PowerShell 和 conda 配合使用时，务必把配置文件的加载原理弄明白，不要只看表面命令。conda init 之所以比手动改 PATH 更可靠，是因为它把初始化代码放到了 shell 的配置文件里；执行策略之所以重要，是因为 PowerShell 默认拒绝运行 .ps1 文件。明白了这两点，你遇到“找不到 conda”“无法 activate”“VSCode 找不到环境”这些问题时，就能自己判断出方向，不必每次都依赖搜索。
第二点我想说的经验是：尽量让所有开发场景用同一个 shell。我在同一台机器上遇到过 Windows PowerShell 5.1、PowerShell 7、VSCode 内置终端和 Windows Terminal 同时共存的情况，每个环境的 $PROFILE 路径都不同，conda 初始化也分散在不同位置。后来我把所有终端都改成调用 PowerShell 7，并统一在同一个 $PROFILE 里加载 conda 初始化，从此再没出现过“换个终端 conda 就消失”的怪事。建议你也检查一下自己终端的启动来源，尽量减少环境的割裂。
最后一个小技巧：如果你经常被 conda 解析依赖的速度折磨，除了前面说的清理缓存、配置镜像源之外，还可以考虑安装 conda-libmamba-solver 作为默认求解器，它是 conda 23.x 之后官方主推的新依赖解析器，在多版本依赖较多的项目里速度提升非常明显。安装命令：
powershell复制conda install -n base conda-libmamba-solver
conda config --set solver libmamba
这一行配置对日常使用体验的提升，比我试过的很多临时“加速方法”都要显著。希望这篇个人心得能帮你把 PowerShell 和 conda 的组合真正理顺，之后在这些基础之上，再折腾什么项目环境配置，都会顺手很多。