conda list 中出现 pip 标记说明该包由 pip 安装，脱离 conda 依赖管理，易引发 UnsatisfiableError；应强制卸载后用 conda 重装，尤其警惕 numpy、pytorch 等含 C 扩展的包。
conda list 里看到 pip 就要警觉
运行 conda list 后，如果某行的 Status 列显示 pip，说明这个包不是 conda 安装的，而是 pip 插入的。这类包会脱离 conda 的依赖图管理，后续任何 conda install 都可能因无法满足其隐式约束而报 UnsatisfiableError。
- 优先用
conda remove --force 包名卸载它，再用conda install -c conda-forge 包名重装（哪怕只是重装同一版本） - 特别警惕
numpy、scipy、pytorch、tensorflow这类含 C 扩展的包——pip 安装的 wheel 往往链接系统级库，和 conda 自带的 MKL/cuDNN 不兼容 - 检查
pip list和conda list输出是否一致；不一致时，以conda list为准，pip的状态不可信
environment.yml 里混写 pip 和 conda 依赖会直接卡死求解器
conda 原生求解器看到 pip: 段落，尤其当里面包含 llvmlite、numba、torch 这类需本地编译或带二进制绑定的包时，会放弃整条依赖路径，直接报错。
- 把所有
pip:下的包从environment.yml中删掉，单独存为requirements.txt - 先用
conda env create -f environment.yml创建纯 conda 环境 - 再激活环境，执行
pip install -r requirements.txt——此时 pip 只负责 Python 层，不碰底层 C 库 - 若
requirements.txt里有-e git+https://...，确保它不依赖 conda 管理的 C 扩展（如不 import torch 或 numpy）
import torch 报 libtorch_cpu.so 找不到，本质是 runtime linker 失效
这不是缺文件，而是动态链接器没在 conda 环境的 lib/ 目录下搜到 libtorch_cpu.so。常见于：跨 channel 混装（defaults + conda-forge）、非标准 prefix 路径、或 pip 替换了 conda 安装的 pytorch。
- 运行
ldd $(python -c "import torch; print(torch.__file__)") | grep "not found"确认缺失哪些 so - 检查
conda list torch输出的 build 字符串，确认是否含cuda或cpuonly标签，和你的硬件匹配 - 临时修复：把 conda 环境的
lib/加进LD_LIBRARY_PATH（Linux）或DYLD_LIBRARY_PATH（macOS），但这是权宜之计 - 根治：重建环境，全程只用
mamba create -n envname -c conda-forge python=3.11 pytorch torchvision
Python 3.12 在 conda-forge 上仍不完整，别硬上
截至 2026 年中，pytorch、tensorflow、numba 在 conda-forge 上对 python=3.12 的 wheel 支持仍断断续续，很多包只能源码编译，一编就崩。这不是你配置的问题，是生态还没跟上。
- 在
environment.yml或conda create命令中显式写python=3.11 - 不要用
python>=3.12或python=3.*—— conda 会默认选最新，直接撞墙 - 验证：创建后运行
python -c "import sys; print(sys.version)"和conda list python，双确认版本一致
复杂点在于：conda 的依赖求解是全局 SAT 问题，而 pip 是局部递归安装。一旦混用，你就同时在两个不同逻辑的系统里改同一个环境——表面看只是少装一个包，实际已破坏整个约束图的可满足性。最容易被忽略的是，pip install 后不重启 Python 解释器，import 仍可能命中旧缓存，让你误判“好像装上了”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
