我很高兴地通知您，使用 Mamba 基本上没有严格的缺点！它始于 2019 年 3 月，最初是对 Conda 的一个精简包装，并通过使用等效的新高效 C++ 代码逐步重写 Conda 得到了显着发展。他们添加了 Mamba 独有的功能，例如mamba repoquery. Conda 和 Mamba 都使用 BSD 3-Clause 许可证，所以没有区别。与 Conda 一样，Mambda 具有良好的跨平台支持。说了这么多，有几点需要注意：

• 与 Conda 相比，Mamba 相对较新且不受欢迎。这意味着可能有更多未被发现的错误，而新的错误可能需要更长的时间才能被发现。也就是说，Mamba 开发人员表现出的敏捷性让我认为他们可能会更快地修复新发现的错误。
• 有相当多的已知错误，尽管Conda 也是如此。
• 前面提到的一些错误是 Mambda 和 Conda 之间的不一致。由于 Mamba 是对 Conda 的重写，因此您不能确定从中获得的行为与从 Conda 中获得的行为完全相同。您可以判断这对您有多重要。大多数 Mamba 用户永远不会遇到这些不一致之处之一。
• 如果您使用 Mamba，遇到错误并报告它，那么处理您的错误报告的人可能不会感谢您使用他们不正式支持的包管理器。随着时间的推移，这可能会变得不那么重要。
• 如果您在脚本中使用 Mamba（例如 shell 脚本、makefile 等），那么如果这些脚本的用户有 Conda 而没有 Mamba，他们可能会遇到问题。在大多数情况下，他们会简单地能够取代命令conda用mamba，但是如果你使用专属曼巴的特点，他们将不得不安装mamba。
• 一些组织已批准使用 Conda，但未批准使用 Mamba。在上述场景中，这意味着来自这些组织的用户将不得不重写所有mamba命令conda（即安装 Mamba 不是这些用户的选项，除非他们想等待他们的法律团队等批准使用Mamba），并且如果您使用独有的 Mamba 功能，那么它们就是不走运，将无法运行这些命令。
• Mamba 的机构支持（在撰写本文时目前只是由 Bloomberg 资助的 QuantStack）并不像Conda 所拥有的机构支持那么强大，尽管它们看起来确实很活跃，所以我现在不会担心. 最坏的情况：项目被放弃，没有人分叉它，它变得陈旧。您和所有其他使用它的人必须回到 Conda（或一些新的替代方案），并相应地更新您的mamba命令。所有使用专有 Mamaba 功能的命令都必须删除或替换为更复杂的命令。但这是最坏的情况，而且似乎不太可能。

总而言之，这些都是相当小的问题。我预计 Mamba 会随着时间的推移继续流行，甚至可能在未来将其代码集成到 Conda 中。