必须显式指定python=版本，否则新环境默认继承base的python版本，导致c扩展包（如tensorflow、numpy）因abi不兼容而导入失败；应通过requirements.txt等确认项目所需python次版本号。
Anaconda 解决版本冲突的核心方式不是“修复已发生的冲突”，而是从源头避免——用 conda create 创建隔离环境，让每个项目独占 Python 解释器和包版本。
为什么 conda create 必须显式指定 python= 版本
不写 python=3.8 而只写 conda create -n myenv，新环境会默认继承 base 的 Python 版本。一旦 base 是 3.11，而你的旧项目依赖 tensorflow==1.15（仅支持 Python ≤3.7），import tensorflow 就会直接报 ImportError: DLL load failed 或 ModuleNotFoundError。
- Python 次版本号（如 3.8、3.9）不兼容 C 扩展 ABI，numpy/scipy/tensorflow 等包无法跨版本混用
- 查看项目约束：检查
requirements.txt头部的python>=3.7, 或 <code>pyproject.toml中的requires-python = ">=3.8" - 命令必须带等号：
conda create -n legacy_proj python=3.7，不能写成python 3.7或python=3
pip install 仍装进 base 环境的真相
即使命令行前缀显示 (myenv)，执行 pip install pandas 仍可能把包写进 base 的 site-packages。典型现象是 pip show pandas 显示路径为 C:\anaconda3\Lib\site-packages，而非 C:\anaconda3\envs\myenv\Lib\site-packages。
- 根本原因：Windows 下
pip.exe可能被系统 PATH 缓存或注册表残留劫持 - 安全做法：始终用
python -m pip install pandas，确保调用当前激活环境的解释器 - 验证是否生效：
where pip（Windows）或which pip（macOS/Linux），输出路径必须含envs\myenv
conda install 和 pip install 混用的风险
在同一个 conda 环境里先 conda install numpy，再 pip install numpy，会导致 conda 元数据损坏。后续 conda-pack 打包时抛出 _CondaPackError: Files managed by conda were found to have been deleted/overwritten。
- conda 管理二进制依赖（如 OpenBLAS、CUDA 库），pip 安装的 wheel 不保证 ABI 兼容
- 优先级顺序：conda → pip → 手动编译（除非明确需要 pip-only 包，如
pip install torch官方 CUDA wheel） - 补救措施：若已混用，运行
conda install --force-reinstall numpy恢复 conda 管理状态
真正容易被忽略的点是：环境变量污染比包冲突更隐蔽。比如 PATH 中同时存在 C:\Python39 和 C:\anaconda3\envs\myenv，哪怕你 conda activate myenv，某些 IDE 或脚本仍可能调用错解释器。验证永远比假设可靠——每次操作后，用 python -c "import sys; print(sys.executable)" 看实际路径。
