多年来，想在桌面版之外运行 Postman 集合，基本只有一条路：Newman。后来 Postman 官方推出了命令行工具 Postman CLI，这就有了两个选项，都能脱离 GUI 跑集合，都适配 CI/CD 流水线，执行同样的测试脚本。那问题来了：为什么搞两个？你的流水线到底该选哪个？

一句话概括：Newman 是开源、无需账号的运行器，早期就是社区标配；Postman CLI 是较新的、与账号绑定的工具，跑完结果会同步回 Postman 云端并生成报告。选哪个，取决于你是想依赖 Postman 平台存储结果，还是只想拿着集合文件就跑。下面从几个维度拆开对比，帮你理清思路。

什么是 Newman

Newman 是 Postman 最早的命令行集合运行器，开源、以 npm 包形式分发，完全免费。它读取从 Postman 导出的集合文件，执行每个请求和 pm.test 断言，然后通过退出码报告结果。

Newman 的核心特点就是独立。不需要 Postman 账号、API Key，也不用连 Postman 服务端。你只要给它一个 JSON 集合文件，它就能跑。在受限环境里，这种独立性意味着可预测、易理解。

npm install -g newman
newman run checkout-api.postman_collection.json --environment staging.postman_environment.json

Newman 还很轻量、可扩展。内置了 CLI 和 JUnit 报告器，社区还维护了额外的报告器，比如能生成丰富 HTML 输出的 newman-reporter-htmlextra。因为是 Node.js 包，你也能在脚本里通过编程方式调用它。

什么是 Postman CLI

Postman CLI 是 Postman 官方推荐的新命令行工具。它通过安装脚本分发，是个单一二进制文件，不是 npm 包，通过 API Key 绑定你的 Postman 账号。

# 安装（以 macOS/Linux 为例）
curl -o- "https://dl-cli.pstmn.io/install/osx_64.sh" | sh
# 身份验证，然后运行
postman login --with-api-key YOUR_API_KEY
postman collection run checkout-api

关键区别在于云端连接。用 Postman CLI 跑集合时，它可以直接通过 ID 从 Postman 工作区拉取集合，并把运行结果推回 Postman 平台，结果会出现在工作区的请求历史和仪表板里。最大的卖点是 API 治理和安全检查：Postman CLI 能在流水线里对你的接口定义做 lint 检查，在构建过程中发现数据模型和规则违规。

所以 Postman CLI 不只是一个纯粹的集合运行器，它更像是 Postman 平台的一个流水线袋里。如果你的团队在 Postman 云端协作，希望把运行历史和治理都集中在那里，那这种集成就是选择它的理由。

维度对比

决定性的核心在于 Postman 云端。Postman CLI 的目标是把结果和治理数据反馈回平台；Newman 则是在本地运行文件、生成报告，不依赖 Postman 服务端。

如何在 CI/CD 中应用

两种工具都适用于任何 CI 供应商，包括 Jenkins、GitHub Actions、GitLab CI 和 CircleCI，但运作机制不同。

用 Newman 时，你把集合和环境 JSON 文件提交到仓库，在任务里安装 Newman 并运行，测试失败时非零退出码会导致构建失败。所有内容都在仓库和流水线里。用 Postman CLI 时，你需要把 Postman API Key 作为 Secret 存到 CI 供应商里，认证后通过 ID 运行集合。集合从 Postman 云端拉取（而不是仓库），结果回传到工作区。这让 Postman 成为单一事实来源——有些团队喜欢，有些团队觉得受限。

一个实际区别：Newman 让测试与代码同版本管理（因为集合 JSON 在仓库里），Postman CLI 则在 Postman 平台上管理测试版本（通过 ID 拉取）。选之前，先想清楚你的团队希望哪种方式作为单一事实来源。

治理视角

最能区分两个工具的功能是 API 治理。Postman CLI 可以针对存储在 Postman 工作区中的接口定义执行 postman api lint 风格的检查，根据命名、安全性、数据模型完整性和一致性规则进行评估。当这个检查在流水线里运行时，任何违反规则的定义都会在变更合并前导致构建失败。

Newman 没有这个功能。它只管跑集合、报告测试结果，边界很清楚。如果你的组织需要自动执行接口设计标准，那这个功能只在 Postman CLI 里，是一个真实的选择理由。如果你们不在流水线里强制执行设计规则，那这个功能无关紧要，Newman 的简洁性反而更胜一筹。

这一点值得诚实面对，因为它重新定义了对比。Postman CLI 不只是“更新版的 Newman”，它是一种不同类型的工具——Postman 平台的流水线袋里，恰好包含了一个集合运行器。而 Newman 仅仅是一个集合运行器。一旦这么看，选择就不再只是功能对比，而在于你是否想把测试完全绑定到 Postman 平台上。

迁移考量

已经在用 Newman 的团队有时会问要不要切到 Postman CLI。很少有强有力的理由这么做。Newman 还在维护，依然免费，能在所有 CI 里跑。切换意味着要加 API Key 作为 CI 密钥，改变集合来源方式，还得接受对 Postman 云端的依赖。除非你特别需要集中运行历史记录或治理检查，否则迁移成本高于收益。

从零开始的团队面临更有趣的选择。如果团队把 Postman 作为主要工具并买了付费方案，Postman CLI 可以把一切保持在一个生态里，是自然的选择。如果团队想要灵活性、代码库版本化的测试，以及摆脱对单一供应商云端的依赖，那 Newman 或完全非 Postman 的工具更有意义。没有普适的标准答案，只有最适合你团队现有工作方式的答案。

你该如何选择

如果你想要一个不依赖账号的运行器，希望在代码库中对测试进行版本控制，需要通过社区报告器生成丰富的 HTML 报告，或者在受限环境中运行（不允许访问 Postman 云端），请选 Newman。Newman 的独立性和成熟度让它成为大多数流水线的安全首选。

如果你的团队深度使用 Postman 平台，希望在那里集中查看运行历史记录和仪表盘，或者流水线中的接口治理和接口定义 lint 检查对你很有价值，请选 Postman CLI。对于以 Postman 为中心的团队来说，紧密的云端集成是一个真正的优势。

如果你正在权衡这个决定，值得问问自己是否真的想被绑定在 Postman 生态里。有关其他方法，可以参考我们的指南：如何在没有 Newman 的情况下在 CI 中运行 Postman 集合，以及我们对不使用 Postman 进行接口测试的更广泛探讨。

常见问题解答

Postman CLI 正在取代 Newman 吗？

Postman 将 Postman CLI 定位为其官方推荐的命令行工具，但 Newman 仍在维护且被广泛使用。如果你想要一个无需账号、支持仓库版本管理的 runner，Newman 仍然是更好的选择。两者可能会共存一段时间，因此没有迫切的迁移需求。

Postman CLI 需要 Postman 账号吗？

是的。Postman CLI 使用 Postman API key 进行身份验证，旨在将运行结果连接回你的 Postman 工作区。相比之下，Newman 不需要账号，完全基于本地集合文件运行。

哪个工具的报告更好？

Newman 通过社区报告器提供更灵活的报告功能，特别是用于详细 HTML 输出的 newman-reporter-htmlextra 和用于 CI 仪表盘的 JUnit XML。Postman CLI 将结果报告到 Postman 平台本身，如果你的团队在该平台上工作，这很方便，但对于独立的报告文件来说灵活性较差。

Postman CLI 可以运行本地集合文件吗？

Postman CLI 可以运行本地文件中的集合，但它是围绕通过 ID 从 Postman 云端获取集合并回传结果而构建的。如果你想要一个将本地 JSON 文件视为单一事实来源且无需云端参与的工具，Newman 更自然地契合这种模式。

在 CI 中哪个更快？

对于纯粹的集合执行，差异很小，取决于集合大小和网络状况。Newman 的资源占用更小，且没有云端往返。Postman CLI 增加了身份验证和将结果同步到平台的开销。对于大多数流水线，请根据工作流的契合度而不是原始速度进行选择。