支持Libpod库的RESTful API（5.0.0）
libpod 目前是一个 Golang 库和一个命令行界面（CLI）。您选择的接口具有优势和劣势。
使用 REST API
优势：
- 稳定的、有版本的 API
- 与语言无关
- API 文档完善
劣势：
- 错误处理不如 Golang API 详尽
- 可能较慢
作为子进程运行
优势：
- 许多命令输出 JSON
- 适用于非 Golang 语言
- 易于上手
劣势：
- 错误处理更难
- 可能较慢
- 无法挂钩或控制低级操作，如镜像的拉取方式
将 libpod 添加到 Go 项目中
优势：
- 强大的功能和控制力
劣势：
- 您现在需要负责容器运行时的安全更新（部分上，
runc/crun是分开的） - 二进制文件大小
- 在同一存储上操作多个 libpod 版本时，潜在的版本差异可能导致问题
做出选择
首先，一个很好的问题是：您是否希望用户能够使用 podman 来操作您的项目创建的容器？
如果答案是肯定的，那么使用 REST API 或作为子进程运行可能是更好的选择，因为这允许用户利用 podman 的完整功能集。然而，这也意味着您的项目将依赖于 podman 的存在和可用性。
如果您需要更细粒度的控制或对 libpod 的内部机制有特定的需求，那么将 libpod 添加到您的 Go 项目中可能是更好的选择。这将使您能够直接利用 libpod 的库函数和特性，但也会增加项目的复杂性和维护负担。
在做出选择时，请务必考虑您的项目需求、目标用户群以及维护成本等因素。
确实如此，如果您想要一个独立的镜像存储和完全不同的体验，或者您使用容器的方式与通过 podman CLI 创建的容器非常不同，那么您可能更倾向于将 libpod 添加到您的项目中。
如果您想要运行 podman 作为子进程或使用 HTTP API，那么这更可能是您的选择。这种方式允许您利用 podman 的现有功能和稳定性，同时保持与 podman CLI 用户的兼容性。
然而，如果您需要更高级别的定制和控制，或者您希望与容器运行时的内部机制有更深入的交互，那么将 libpod 直接集成到您的 Go 项目中可能更为合适。这样做将允许您直接访问 libpod 的库函数和特性，从而能够更精细地控制容器的创建、管理和交互。
在选择最佳方案时，请务必考虑您的项目需求、目标用户群、维护成本以及您对容器技术的熟悉程度。不同的选择将带来不同的优势和挑战，因此请根据您的具体情况做出明智的决策。