混用 venv 和 conda 会导致包冲突与解释器路径错乱：venv 继承 conda 解释器后，pip 与 conda 包管理不互通，相互安装可能破坏依赖隔离；应统一选用 venv+pip 或 conda，禁在 conda 激活状态下运行 python -m venv。
venv 和 conda 混用会出什么问题
混用 venv 和 conda 创建的环境，最常见的是包冲突和解释器路径错乱。比如你在 conda 环境里用 python -m venv myenv，结果 myenv 会继承 conda 的 base 解释器，但 pip 和 conda 的包索引不互通，后续 pip install 可能覆盖掉 conda 管理的依赖，反过来 conda install 也可能破坏 venv 的隔离性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 选一个主力工具：项目级协作推荐
venv+pip（轻量、标准、CI 友好）；数据科学/多语言依赖场景用conda（能装非 Python 包，如numpy的 MKL 版本） - 绝对不要在 conda 激活的 shell 里运行
python -m venv，先conda deactivate - 检查当前解释器来源：运行
which python（macOS/Linux）或where python（Windows），确认路径不含anaconda或miniconda才算干净
多个 venv 怎么快速切换且不污染 shell
手动 source venv/bin/activate 容易漏 deactivate，尤其终端开多了之后，python 命令可能指向错误环境，导致 pip 安装到错地方，甚至误升级系统 pip。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别靠记忆切换，用
deactivate显式退出再进下一个 - 给每个 venv 起明确名字，比如
venv-py39-django32，避免venv这种泛化名 - 终端标签页命名：macOS/iTerm 可用
echo -ne "\033]0;django-dev\007"设置标题，一眼识别当前环境 - 临时用法：直接调用 venv 里的解释器，比如
./venv-py39-django32/bin/python manage.py runserver，完全绕过 activate
pyenv + venv 组合时常见的路径陷阱
pyenv 控制全局 Python 版本，pyenv virtualenv 是它封装的 venv 工具。问题常出在 PYENV_VERSION 和 pyenv local 设置后，shell 启动时自动加载了某个版本，但你实际想进另一个 venv —— 此时 python 命令走的是 pyenv 的 shim，不是 venv 的 bin。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 进 venv 前先确认：运行
pyenv version，如果是system或某个具体版本（如3.11.5），说明 pyenv 还在接管；要进 venv 就得先pyenv shell --unset或pyenv shell system -
pyenv virtualenv创建的环境本质仍是标准 venv，只是目录被收归~/.pyenv/versions/下，激活方式一样：source ~/.pyenv/versions/myproject-311/bin/activate - 别把
.python-version和venv目录放在同一层：pyenv 会优先读.python-version，可能让你以为进了 venv，其实只是切了 Python 版本
如何让不同项目自动加载对应 venv
每次 cd 进项目都要手动 source，容易忘。虽然有 autoenv、direnv 这类工具，但它们依赖 shell hook，权限敏感、调试困难，尤其在远程服务器或 CI 中反而添乱。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 最稳的方式：在项目根目录放一个
run.sh或dev.sh，内容就三行：#!/bin/bash source ./venv/bin/activate exec "$@"
然后./dev.sh python manage.py runserver - 如果坚持自动化，用
direnv，但只在本地开发机用，且必须加export DIRENV_STRICT_ENV=1防止变量泄露 - VS Code 用户：在
.vscode/settings.json里配"python.defaultInterpreterPath": "./venv/bin/python"，比 shell 自动化更可靠
真正麻烦的从来不是创建多少个环境，而是哪个 shell 进程此刻认的是哪个 python、哪个 pip、哪个 sys.path。多看一眼 which python 和 python -c "import sys; print(sys.path)"，比背十种管理工具都管用。
