conda管环境（含Python解释器、CUDA、MKL等系统级依赖），uv pip管纯PyPI包（如requests、fastapi），二者职责互补：conda确保底座稳定，uv提供更快安装、更强锁定与更准依赖解析。
conda create 之后，为什么还要用 uv pip install
因为 conda 管环境，uv 管包——两者职责不重叠，反而互补。conda 创建的环境里，Python 解释器、CUDA、MKL、OpenBLAS 这些系统级依赖已经就位；但 requests、fastapi、transformers 这类纯 PyPI 包，conda 安装慢、锁版本弱、生态更新滞后。这时候用 uv pip install 替代 pip install，能直接复用 conda 环境的底层能力，同时获得 10–100 倍的安装速度和更严格的依赖锁定。
常见错误现象：
- 在 conda 环境里直接
pip install torch，结果装了 CPU 版本，而 conda 当前环境明明配好了 CUDA； - 用
conda install pandas装完，发现版本是 1.5.x，但项目要求 2.2+； -
environment.yml导出后别人还原不了，因为某些包只在 PyPI 有、conda 频道没同步。
实操建议：
- 先
conda activate myenv，确保当前 shell 处于目标环境； - 用
uv pip install --index-url https://download.pytorch.org/whl/cu121 torch显式指定源，避免混装； - 不要在 conda 环境里再跑
uv venv——这会套娃创建新虚拟环境，破坏 conda 的隔离语义； - 如果项目要提交依赖锁定，优先用
uv export > requirements.txt，它比pip freeze更准（会过滤掉 conda 自带的非 PyPI 包）。
uv python install 和 conda install python 的根本区别
uv python install 下载的是预编译的 CPython 二进制，存在全局缓存（如 ~/.local/share/uv/python），多个项目可共享同一份解释器；conda install python 是把 Python 当作一个 conda 包来装，每个环境都有一份独立副本，连同 MKL、OpenSSL、zlib 等依赖一起打包进去。
立即学习“Python免费学习笔记（深入）”；
这意味着：
- 用
uv python install 3.12+uv venv --python 3.12，适合 Web/API/CLI 类轻量项目，启动快、磁盘省； - 用
conda create -n ml-env python=3.12，适合需要cudatoolkit、gdal、r-base的科研或 AI 项目，环境自洽但体积大； - 如果你已在用 conda 管理 Python 版本，就别再用
uv python install——它不会干扰 conda，但也没必要重复下载。
容易踩的坑：
- 在 conda 环境中执行
uv python list，看到的只是 uv 自己缓存的 Python 版本，和当前 conda 环境无关； - 误以为
uv python install能装 PyPy 或 GraalPy ——它支持，但 conda 不支持，混用可能导致 ABI 不兼容； - 用
uv python install装了 3.13，又用 conda 创建python=3.13环境，结果两个 3.13 的sysconfig.get_platform()返回不同值（一个是linux-x86_64，一个是linux-conda-x86_64）。
pyproject.toml + uv.lock 与 environment.yml 的协同方式
二者不是替代关系，而是分层锁定：environment.yml 锁定系统级依赖（Python、CUDA、FFmpeg），uv.lock 锁定 Python 包层级依赖（exact versions + hashes）。实际协作时，environment.yml 是“底座声明”，uv.lock 是“应用层契约”。
典型工作流：
- 团队统一维护一份
environment.yml，含python=3.12、cudatoolkit=12.1、ffmpeg等； - 每个项目有自己的
pyproject.toml和uv.lock，通过uv add增删包； - CI 中先
conda env create -f environment.yml，再uv pip install -r requirements.txt（或直接uv sync）； - 导出时不用
conda env export，改用conda env export --from-history > environment.yml，避免把 uv 安装的 PyPI 包也塞进去。
性能影响：
-
uv.lock文件小（KB 级）、解析快（毫秒级），适合 Git 提交和 CI 缓存； -
environment.yml体积大（MB 级）、求解慢（分钟级），适合一次性部署或离线镜像； - 混合使用时，
uv lock不会校验 conda 包的 hash，所以必须确保environment.yml的底座稳定——否则uv.lock再准也没用。
Windows 上 conda + uv 协同的 PATH 和激活陷阱
Windows 的 PowerShell 和 cmd 对 conda 激活机制处理不同，而 uv 又依赖当前环境的 PYTHONPATH 和 Scripts 目录。最容易出问题的点是：uv 命令能运行，但实际安装的包却进了 base 环境或系统 Python。
验证方法：
- 激活环境后，运行
where uv，输出应为D:\Conda\envs\myenv\Scripts\uv.exe（Windows）或which uv输出含envs/myenv（macOS/Linux）； - 运行
uv pip show requests，看Location:是否指向 conda 环境路径； - 若用 VS Code，检查右下角 Python 解释器路径是否和
conda activate后的which python一致。
关键细节：
- 不要用
pip install uv在 conda 环境里装 uv——它可能被 pip 误判为“用户安装”，导致 PATH 错乱； - 推荐用官方脚本全局安装 uv（
irm https://astral.sh/uv/install.ps1 | iex），再在 conda 环境中直接调用； - PowerShell 默认禁用脚本执行，首次运行需手动设
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser； - Conda 初始化脚本（
conda init powershell）必须运行过，否则conda activate不生效，uv 就找不到正确的环境上下文。
