VSCode终端启动时PATH被覆盖导致conda环境失效，根源在于VSCode注入的初始PATH不含conda路径、PowerShell执行策略阻止profile加载、自定义terminal profile绕过初始化，以及PYTHONEXECUTABLE变量强制锁定解释器。
终端启动时 PATH 被 VSCode 覆盖
VSCode 启动集成终端时，会把自身启动时读取的系统 PATH 直接注入新 shell 进程，而这个 PATH 往往不含 conda 或 venv 的 bin/Scripts 目录——哪怕你已经在 shell 里手动 conda activate myenv 过。结果就是：终端里 python --version 显示的是系统默认版本，where python（Windows）或 which python（macOS/Linux）返回的也不是虚拟环境路径。
关键点在于：PATH 注入发生在 shell 初始化之前，conda 的 hook 还没来得及修改它。
- 验证方式：在 VSCode 终端里执行
echo $env:PATH（PowerShell）或echo $PATH（bash/zsh），看输出里有没有你的 conda env 路径（如C:\miniconda3\envs\myenv\Scripts）或 venv 路径（如./venv/Scripts） - 临时绕过：手动运行
conda activate myenv或source ./venv/bin/activate，但每次新开终端都要重复 - 根治办法：启用
python.terminal.activateEnvironment设置，并确保终端 profile 正确加载 conda hook（见下一条）
PowerShell 执行策略阻止 conda hook 加载
Windows 上 PowerShell 默认执行策略为 Restricted，会直接跳过 $profile 中的脚本——包括 conda 自动注入的初始化代码。这就导致 conda activate 命令本身可能不可用，更别说自动激活了。
现象是：终端一打开就报错 File C:\Users\...\profile.ps1 cannot be loaded because running scripts is disabled...，或者 conda 命令根本不存在。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 检查当前策略：
Get-ExecutionPolicy -Scope CurrentUser - 仅对当前用户放宽（推荐）：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 确认 conda hook 已写入：
notepad $PROFILE，检查是否存在类似(& "C:\miniconda3\shell\condabin\conda-hook.ps1") | Out-String | Invoke-Expression的行 - 改完后重启 VSCode，否则旧终端进程不会重读 profile
vscode terminal.integrated.profiles.windows 配置绕过了 shell 初始化
如果你在 settings.json 里自定义了 terminal.integrated.profiles.windows，比如指定了 "powershell": { "path": "pwsh.exe" } 或直接用了 cmd.exe，那 VSCode 就不会走默认的 PowerShell 启动流程——也就不会加载 $PROFILE，conda hook 彻底失效。
这不是 bug，是设计行为：自定义 profile 意味着你接管了 shell 启动逻辑。
- 安全做法：删掉
terminal.integrated.profiles.windows配置项，让 VSCode 用默认 profile - 若必须自定义，需显式带入 profile 加载，例如：
"args": ["-NoExit", "-Command", "if (Test-Path $PROFILE) {. $PROFILE}"] - 注意不要混用
pwsh和powershell：前者不默认加载$PROFILE，后者才加载
PYTHONEXECUTABLE 环境变量强行锁定解释器
如果某个父进程（比如你从命令行启动 VSCode 时的 shell）设置了 PYTHONEXECUTABLE，VSCode 继承了它，那么无论你选哪个解释器、终端是否激活环境，Python 子进程都会优先使用这个变量指定的路径。
这会导致调试器和终端行为割裂：调试器跑的是 PYTHONEXECUTABLE 指向的解释器，终端跑的是 PATH 找到的——看起来像“环境错位”，实则是被硬编码覆盖。
- 排查命令：
echo $env:PYTHONEXECUTABLE（PowerShell）或echo $PYTHONEXECUTABLE（bash/zsh） - 临时清除：
Remove-Item Env:\PYTHONEXECUTABLE（PS）或unset PYTHONEXECUTABLE（bash） - 永久清理：检查 shell 的
.zshrc、profile或 VSCode 启动快捷方式的“起始位置”参数，删掉相关 export
真正麻烦的不是 PATH 顺序或 profile 加载，而是这些机制层层叠加：执行策略拦住 hook，hook 失效导致 PATH 不更新，PATH 错位又让 PYTHONEXECUTABLE 变得更难察觉。每一步单独看都简单，串起来就容易漏掉中间那个“静默失败”的环节。
