官方文档和本博客在同一个网站上-建议使用conda安装尽可能多的需求，然后使用pip。显然，这是因为conda将不知道pip对依赖项所做的任何更改，因此将无法正确解析依赖项。
现在，如果一个人只使用pip而不安装任何带有conda的东西，那么似乎有理由期望conda不需要意识到由pip-作为conda有效地成为隔离依赖关系和管理版本的工具。然而，这违背了官方的建议，因为我们不会使用conda安装尽可能多的需求。
因此问题依然存在：在conda环境中独家使用pip是否存在已知的缺点？
这里稍微涉及了中的类似主题，但没有涉及在conda环境中专门使用pip的情况。我也来过这里：
我们不确定能否就此给出一个全面的答案，但我想到的一些主要问题是：
>
缺乏对非Python依赖项解析的深度支持。随着时间的推移，捆绑非Python资源的轮子越来越多，但它远没有康达作为通用包管理器而不是特定于Python提供的覆盖范围。对于任何从事可互操作计算的人（例如，networkite），我希望康达会受到青睐。
优化库。有点与第一点相关，但Anaconda团队已经努力构建优化版本的软件包（例如，MKL fornumpy）。不确定是否可以通过PyPI获得等效项1
跨环境的浪费冗余。当包和环境位于同一卷上时，Conda使用硬链接，并支持跨卷的软链接。这有助于最大限度地减少复制安装在多个环境中的任何软件包。
使出口复杂化。导出（conda env export）时，conda不会拾取所有pip-安装的软件包-仅拾取来自PyPI的软件包。也就是说，它将错过从GitHub安装的东西，等等。。如果有人真的选择了pip-only路线，我认为更可靠的出口策略是使用pip冻结
channels:
- defaults
dependencies:
- python=3.8 # specify the version
- pip
- pip:
- -r requirements.txt
用它来重建环境。
综上所述，我可以很容易地想象，对于某些人来说，这些都无关紧要（大多数都是方便），尤其是那些倾向于纯用Python工作的人。然而，在这种情况下，我不明白为什么不干脆放弃Conda，而使用特定于Python的虚拟环境管理器。
[1]如果你不知道，请有人纠正我
