在生产环境中使用 ConanCenter 包¶
ConanCenter 是一个极好的资源，包含了社区贡献的 1500 多个库和应用程序的配方参考实现。因此，它是关于如何为开源依赖项创建和构建 Conan 包的宝贵知识库。
ConanCenter 还为各种配置构建并提供二进制包：多个操作系统（Windows、Linux、macOS）、编译器、编译器版本和库变体（共享、静态）。最重要的是，对于许多库，社区贡献者确保配方与其他操作系统（Android、iOS、FreeBSD、QNX）和 CPU 架构兼容。Conan Center 中的配方是 Conan 通用性承诺的最佳例证。
与其他包管理器或仓库不同，ConanCenter 不会维护版本的固定快照。相反，对于给定的库（例如 OpenCV），会同时积极维护多个版本。这使用户能够更好地控制使用哪些版本，而不是必须固定到旧版本，或强迫他们始终使用最新版本。
为了支持这个生态系统，ConanCenter 配方会非常频繁地更新。配方本身可能会更新以支持新平台、修复错误，或要求使用更新版本的依赖项。另一方面，每个 ConanCenter 用户可能在其需求中具有不同的版本组合。这意味着，在给定相同的输入需求列表的情况下，Conan 可能会在不同的时间点以不同的方式解析依赖关系图——解析到不同的配方修订版、版本或包。这类似于其他语言中包管理器的默认行为（pip/PyPi、npm、cargo 等）。因此，在需要可重复性的生产环境中，不建议以不受约束的方式直接依赖 Conan Center。
以下指南包含一系列建议，以确保可重复性、可靠性、合规性以及在适用情况下启用自定义的控制。总之，在使用 ConanCenter 中的包时，强烈建议遵循这些方法
可重复性和再现性¶
如前所述——在给定一组需求的情况下，ConanCenter 中的更改会导致 Conan 依赖项解析器随着时间的推移解析不同的依赖关系图。这不仅适用于库的实际版本（例如 opencv/4.5.0 而不是 opencv/4.2.1），还适用于配方本身。也就是说，opencv/4.5.0 配方可能存在多个修订版，这可能会对使用者产生副作用。配方中的更改通常是为了解决问题（修复错误）、实现功能（例如添加条件选项、支持新平台）或更改依赖项的版本。
为了确保可重复性，强烈建议在使用者端使用锁定文件：请查看 锁定文件文档 以获取更多信息。
锁定文件确保 Conan 将以可重复且一致的方式解析相同的依赖关系图——从而确保在多个系统（CI、开发人员等）中使用相同的版本。
锁定文件也用于其他包管理器，如 Python pip、Rust Cargo、npm——这些建议与这些其他技术的实践一致。
此外，强烈建议您在自己的服务器上托管您的配方和包（见下文）。这两种方法都有助于您控制何时将 ConanCenter 的上游更改传播到您的团队和系统中。
服务可靠性¶
在 ConanCenter 远程服务器出现停机时间（计划内或计划外）期间，使用来自 ConanCenter 远程服务器的配方和包可能会受到影响。虽然会尽一切努力确保 ConanCenter 始终可用，并且计划外的停机时间很少见并会得到紧急处理——但这会影响直接依赖 ConanCenter 的用户。此外，当从源代码构建配方时，这需要从 ConanCenter 控制范围之外的远程服务器检索源包（通常是 zip 或 tar 文件）。偶尔，这些服务器也会遇到计划外的停机时间。
在需要高可用性的企业生产环境中，强烈建议您在自己的服务器上托管配方和二进制包。
这还可以防止瞬态网络问题，以及由从外部源传输二进制数据引起的问题。这些建议也适用于在任何包管理器中使用来自外部源的包。
合规性和安全性¶
某些行业（如金融、机器人和嵌入式）对变更管理、开源许可证和可重复性有更高的要求。例如，配方中的更改可能导致为依赖项解析一个新版本，而该版本的许可证已更改，需要您的组织进行验证和审计。在某些行业（如医疗或汽车）中，您可能需要确保所有依赖项都能够以可重复的方式从源代码构建，因此可能不建议使用 Conan Center 提供的二进制文件。在这些情况下，我们建议您从源代码构建自己的二进制包
控制和自定义¶
依赖项的用户通常需要对外部库进行自定义更改——通常是为了支持 ConanCenter 或原始库作者未考虑的特定平台配置、向后移植错误修复等。其中一些更改可能不适合合并到 ConanCenter 中，并且在 ConanCenter 维护人员审查和验证之前可能不会发生。因此，如果您需要严格控制配方中的更改，则强烈建议您不仅托管一个 Conan 远程服务器，还要托管您自己的 conan-center-index 配方仓库分支。
以下小节将更详细地描述上述策略