Bruno：把 API 集合放进 Git 的离线客户端，值不值得换掉 Postman
用于探索和测试 API 的开源 IDE（Postman/Insomnia 的轻量级替代品）
秒懂
- 它是什么？
- Bruno 是一个以本地文件夹和 Bru 纯文本标记语言为核心的 API 客户端，强调离线与 Git 协作。本文基于其 README 与仓库信息，分析它的工作机制、适用场景和明显边界。
- 适合谁用？
- Bruno 适合那些已经用 Git 管理代码、希望 API 集合能走同一套评审和版本流程的个人或小团队，尤其是对数据隐私敏感、不愿把请求历史放到云上的用户。不适合需要团队内实时共享集合状态、依赖云端同步或深度集成 Postman 生态（如 Newman 报告、云 Mock）的团队。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Postman 的云端模式，Bruno 用文件夹来对抗
Postman 把集合存在云端，多人协作靠共享工作区。Bruno 反过来，集合直接落在你电脑的文件夹里，请求信息用一种叫 Bru 的纯文本标记语言保存。README 里写得很直接：Bruno 是 offline-only，而且明确说永远不打算加云同步。这个立场不是技术妥协，是产品哲学。对受数据合规约束的团队，这可能是卖点；对习惯打开 Postman 就能看到队友最新改动的团队，这是需要重新适应的硬约束。
Bru 文件是什么，为什么它让 Git 协作成为可能
Bru 是 Bruno 存储请求的格式，本质是纯文本。这意味着一个请求就是一个文本文件，可以用 Git 做 diff、做 review、回滚。README 强调你可以用 Git 或任何版本控制工具协作。机制上，集合目录里的每个 .bru 文件对应一个请求，环境变量、脚本也以类似文本形式存在。这带来的好处是冲突可以像代码冲突一样处理，而不是在 GUI 里点来点去。但代价是，没有云端数据库，也就没有实时的多端同步。你推送、拉取、合并，才能看到别人的改动。这不是缺陷，是设计选择，但你必须接受。
安装与运行：从 brew 到 Docker，路径不少
Bruno 官方提供各平台二进制下载，也支持常见包管理器。macOS 用 `brew install bruno`，Windows 有 `choco install bruno`、`scoop install bruno` 和 `winget install Bruno.Bruno`，Linux 有 `snap install bruno`、`flatpak install com.usebruno.Bruno`，Arch 用户可用 `yay -S bruno`。CLI 工具则从 npm 安装：`npm install -g @usebruno/cli`。在集合目录下，`bru run` 运行全部请求，`bru run request.bru` 跑单个，`bru run folder --env Local` 指定环境跑某个文件夹。Docker 镜像也提供，`docker run -v $(pwd):/bruno usebruno/cli run` 可以直接跑当前目录的集合，适合 CI。安装选项足够多，但注意 CLI 和 GUI 是两个东西，CLI 需要 Node.js 环境，除非你用 Docker。
CLI 与 Docker：自动化测试的入口，但能力边界要查文档
Bruno CLI 的价值在于把集合跑进 CI/CD 管道。README 给出三个基本命令，但没展开断言、脚本、变量注入这些细节。它提到完整的命令参考在官方文档里。这意味着 CLI 不是简单的 `bru run` 就完事，你可能需要查文档写测试断言、处理环境文件。Docker 镜像有 alpine 和 debian 变体，支持 amd64 和 arm64，这比很多工具只提供一种架构要好。但要注意，CLI 跑的是集合里的请求，如果集合依赖 GUI 里才有的交互式脚本或界面状态，CLI 可能跑不通。文档说得很清楚的部分是命令本身，没说清楚的部分是它和 GUI 的功能对齐程度。
一个明显的限制：没有云同步，协作完全押注在 Git 上
Bruno 的离线模式是卖点，也是最大的限制。README 明确说没有云同步计划，这意味着你无法像 Postman 那样在手机上查看集合，也无法让非技术同事通过链接访问请求。Git 协作要求每个参与者都懂 Git 的基本操作，至少会 commit、push、pull 和解决冲突。如果你的团队里有不熟悉 Git 的测试人员，Bruno 的学习曲线会比 Postman 高。另外，纯文本格式虽然适合 diff，但 Bru 语言本身的表达能力有限，复杂的工作流（比如多步骤的认证流程、动态数据生成）可能不如 Postman 的图形化脚本直观。这些在 README 里没有详细说明，但基于其存储机制可以推断。
替代方案：Postman 和 Insomnia 的云端与本地之争
Postman 是 Bruno 直接对标的产品，它把集合和协作放在云端，提供团队工作区、云端 mock、文档托管。Insomnia 则更接近本地优先，但它有云同步的付费选项。Bruno 和这两者的根本区别是：Postman 和 Insomnia 都有官方云服务，Bruno 没有。这意味着如果你需要跨设备实时同步，Bruno 做不到。如果你需要与外部协作者共享一个只读链接，Bruno 也不提供。但如果你已经用 Git 管理代码，Bruno 的集合可以像代码一样被 review，这是 Postman 的云端模式难以比拟的。Insomnia 虽然也支持 Git 同步，但那是通过插件或付费功能，Bruno 把 Git 作为默认的协作方式，这是它的差异化。
许可证与维护：MIT 下的开放，但商标归个人
Bruno 使用 MIT 许可证，这意味着你可以自由使用、修改、分发，甚至商用。但注意 README 里写明 Bruno 这个名称是 Anoop M D 持有的商标，Logo 来自 OpenMoji，采用 CC BY-SA 4.0 许可证。这意味着你可以改代码，但不能随便用 Bruno 这个名字做商业产品。仓库最近更新频繁，v4.1.0 在 2026 年 8 月发布，说明项目活跃。但活跃不代表稳定，你需要关注版本变化，特别是 CLI 的命令和 Bru 格式是否兼容。升级成本方面，如果 Bru 格式有变化，旧集合可能需要手动迁移，文档里没有明确保证向后兼容。
编辑结论
Bruno 适合那些已经用 Git 管理代码、希望 API 集合能走同一套评审和版本流程的个人或小团队，尤其是对数据隐私敏感、不愿把请求历史放到云上的用户。不适合需要团队内实时共享集合状态、依赖云端同步或深度集成 Postman 生态（如 Newman 报告、云 Mock）的团队。采用前先验证三件事：你的 Git 工作流能否接受二进制无关的纯文本冲突合并；CLI 的 `bru run` 是否能覆盖你现有的断言和脚本需求；以及团队是否愿意放弃 Postman 的云端分享和协作功能。Bruno 的离线承诺是明确的，但它的协作方式完全依赖 Git，这不是一个工具替换，而是一套工作流迁移。
社区笔记