官方documentation 和这个blog 在同一个网站 - 建议使用conda 安装尽可能多的要求 然后使用pip。显然这是因为conda 不知道pip 对依赖项所做的任何更改，因此无法正确解析依赖项。
现在，如果一个人专门使用pip 并且不使用conda 安装任何东西，那么期望conda 不需要知道pip 所做的任何更改似乎是合理的——因为conda 实际上变成了一个隔离依赖关系和管理版本的工具。但是，这违反了官方建议，因为不会使用conda 安装尽可能多的要求。
所以问题仍然存在：仅在conda 环境中使用pip 是否有任何已知的缺点？
在here 中触及了一个类似的主题，但不包括在conda 环境中专门使用pip 的情况。我也来过：
【问题讨论】：
标签： python python-3.x pip anaconda conda
不确定是否可以对此给出全面的答案，但我想到的一些主要问题是：
缺乏对非 Python 依赖解析的深度支持。虽然随着时间的推移，越来越多的捆绑非 Python 资源的轮子变得可用，但它远不及 Conda 作为通用包管理器而不是 Python 特定资源所提供的覆盖范围。对于任何从事互操作计算的人（例如，reticulate），我希望 Conda 会受到青睐。
优化的库。有点与第一点有关，但 Anaconda 团队已经努力构建优化版本的包（例如，MKL 代表 numpy）。不确定是否可以通过 PyPI 获得等价物。1
跨环境的浪费冗余。当包和环境在同一个卷上时，Conda 使用硬链接，并支持跨卷的软链接。这有助于最大限度地减少复制安装在多个环境中的任何包。
复杂的导出。导出 (conda env export) 时，Conda 不会拾取所有 pip 安装的包 - 只有来自 PyPI 的包。也就是说，它会遗漏从 GitHub 等安装的东西。如果确实走 pip-only 路线，我认为更可靠的导出策略是使用pip freeze > requirements.txt，然后制作类似 YAML 的文件
channels:
- defaults
dependencies:
- python=3.8 # specify the version
- pip
- pip:
- -r requirements.txt
用来重建环境。
话虽如此，我可以很容易地想象这些对某些人来说都不重要（其中大部分是为了方便），尤其是那些倾向于纯粹使用 Python 工作的人。但是，在这种情况下，我不明白为什么不干脆完全放弃 Conda 并使用特定于 Python 的虚拟环境管理器。
[1]如果你知道，请有人纠正我。
【讨论】：
numpy 默认为 OpenBLAS，可与 MKL 相媲美，据我所知，它们的性能取决于硬件是否为 Intel/AMD。所以也许这不是一个缺点，但仍然很高兴知道