我摊牌了用了五六年 Postman前阵子彻底把它从主力工具位上请了下去。先别急着说我冲动你先看两个数字安装包 10MB 出头双击到能发请求体感不到 1 秒。这不是个玩具项目而是一款具备完整请求编辑、环境变量、脚本断言、导入导出、命令行跑自动化测试的开源 API 客户端。最近我日常的接口调试、回归测试、给团队同步接口文档全在这一个工具里跑。这篇文章就围绕这个“10MB 的 Postman 替代品”展开。我会先讲清楚我为什么想换掉 Postman再解释选型逻辑和核心原理接着把安装、迁移、脚本、自动化、CI 实战都过一遍最后整理一份我在迁移过程中真实踩过的坑和排查记录。如果你是 Postman 的重度用户或者团队正在为协作成本发愁这篇文章应该能给你省下不少时间。1. 为什么要换掉 Postman一个老用户的真实痛点1.1 从“轻巧小工具”到“全家桶”的变化我对 Postman 本身没有恶意它曾经是最好用的接口调试工具没有之一。我最早用 Postman 的时候它还只是个 Chrome 插件开一个标签页就能发请求响应速度又快界面也清爽。后来从插件变成桌面应用功能越来越多同步、云端协作、Mock Server、监控、API 文档、API 网络……什么都有了可体感也一年比一年重。最直观的问题是启动速度。我办公电脑是几年前的中端 ThinkPad配置不算差但每次打开 Postman都要先在后台转好几秒图标有时候启动完了还要等它检查更新、加载工作区真正能动手发请求基本要十几秒。内存占用更是夸张只是开着两三个集合不跑任何请求内存轻松破 500MB。家里那台老笔记本更明显开着 Postman 再开个微信和浏览器风扇就开始狂转。除了性能登录也是一个绕不开的点。新版 Postman 越来越强调账号体系很多功能不登录用不了登录之后又默认把集合往云端同步。对个人用户还好对部分企业环境来说接口数据是不能随便上云端的。很多人其实一直在找“免登录版本”本质就是不想被账号和云同步绑架。还有更新。Postman 的更新频率很高动不动就提示有新版本安装包也越做越大有些版本体积已经到几百MB。装的时候要折腾一遍装完发现界面又改了查个设置项都要重新找。有几次团队里有人升级了新版本导出的集合文件旧版本打不开协作效率直接打折。我不是说 Postman 不好而是它已经从一个“调试工具”长成了“全家桶”。如果你只是想把接口调通、把自动化跑起来它给的一大半东西用不上但占用的资源却一点没少。这种情况下找一款轻量的替代品是顺理成章的事。1.2 我理想中的调试工具长什么样被 Postman 的资源占用和登录墙折磨了一段时间后我给自己列了一份理想工具的清单大概有五条。第一本地优先不强制登录。接口集合、环境变量、脚本这些都是本地文件最好能直接放进 Git 仓库里管理。我不要一个“中心化云端”来管我的数据接口信息是团队资产用 Git 做版本管理比云同步更可控。第二启动快、占用低。打开一个 API 工具应该像打开记事本一样双击就出界面发请求不卡顿。别每次开工具都要等风扇转起来这会直接影响调接口的心情。第三常用功能不能少。集合管理、环境变量、全局变量、请求头/请求体编辑、响应预览、Cookie 管理、脚本断言、批量导出 curl这些必须齐全。我可以接受它没有 Mock Server 和监控面板但日常写接口调试的基本盘不能缺。第四能和 Postman 迁移无缝衔接。不是所有人都从零开始很多人手里已经积累了几十个集合和一堆环境变量。替代品至少要支持导入 Postman Collection 的 JSON 导出文件最好也支持导出给 Postman 用这样团队切换的成本才会低。第五源码开放最好有 CLI。开源的意义在于哪天官方不对劲了社区能接得住CLI 的意义在于我本地调好的接口测试可以直接在 CI 里跑不需要人工点来点去。按这个清单去筛能打的其实没有想象中多。最后进决赛圈的是一款文件存储型的开源客户端——Bruno它在 GitHub 上相当活跃安装包体积只有 10MB 级别启动速度用“秒开”形容毫不夸张。后面几章我会把我这几周的使用体验完整拆开讲。2. 选型思路哪些项目撑得起“10MB 替代品”这块招牌2.1 市面上几款轻量客户端的横向对比围绕“轻量”这个目标我实际试过几款常见工具包括 Hoppscotch、Insomnia、Postman 官方轻量版和 Bruno。先说结论各有强项但最贴合“10MB、1秒启动、不登录、脚本完整”这几个硬指标的是 Bruno。我把它们的关键差异拉了一张表方便你直接对照自己的需求看。维度PostmanInsomniaHoppscotchBruno安装包体积数百MB级100MB左右网页部署或桌面端百MB级10MB级启动速度慢常需数秒中等浏览器打开快约1秒强制登录深度绑定账号可选登录网页端可匿名不登录数据存储云端本地本地为主本地浏览器本地文件(.bru)Git 协作云团队为主支持弱原生支持脚本断言pm.* 丰富支持支持脚本Bru.* / assert 完整导入 Postman 集合天然支持支持支持支持CLI/CI 集成Newman支持有限官方 CLI 支持开源否半开源开源开源这个表其实透露出几个重要信息。Insomnia 是老牌替代品功能确实强界面也现代但它本身也在逐渐变重安装包已经到百MB级别启动速度强于 Postman 但谈不上“秒开”。Hoppscotch 是网页优先的思路适合临时想在线跑个请求的场景但如果你要管理几十个集合、写断言、接入 CI浏览器环境还是差点意思。而且它很多请求能力依赖浏览器策略跨域问题比本地客户端多。Bruno 的设计逻辑是背道而驰的它不是做一个更小的“Postman 克隆”而是把 API 集合当成普通文件来管理。每一个请求就是一个后缀为.bru的文本文件集合目录树在你本地就是真实存在的文件目录。这个设计听起来简单实际用起来却特别省心。2.2 为什么选择 Bruno核心设计值得抄作业很多人听到“轻量替代品”会觉得功能一定缩水我用 Bruno 之前也这么以为。但它把“轻”做成了架构层面的结果而不是靠砍功能硬撑。先说体积为什么能做到 10MB 级。Postman 这类工具本质是一个 Electron 大型应用内置了 DevTools 协议、云同步 SDK、协作服务、权限系统、API 网络浏览器等一系列模块光 UI 组件和依赖就一大堆。Bruno 虽然也是基于 Electron但它的功能边界非常收敛不做云工作区不做团队权限中心不做大规模 UI 框架数据模型就是本地文件和文件夹。应用启动时不需要连接远程服务器不需要加载工作区元数据自然就快。启动过程几乎就是打开一个目录浏览器加请求编辑器加载集合就是遍历本地文件夹这种“轻”不是优化出来的是设计出来的。再说协作为什么方便。Postman 的团队协作核心是把你本地集合同步到云端工作区团队成员各自编辑再合并冲突处理经常让人头大。Bruno 的思路简单粗暴集合就是 Git 仓库里的文件。每个人 clone 仓库改请求、改脚本、改环境变量然后提交 PR。Git 怎么处理代码冲突就怎么处理接口定义冲突——旧方法完全没有。这种设计还有一个隐藏优势接口定义可以参与代码评审。以前改接口配置经常是后端说“我改了你导入一下最新集合”很多时候大家就默默接受了。现在接口文件跟着仓库走Reviewer 能在 PR 里直接看.bru文件的内容变更新增字段、修改 URL、调整断言一目了然。这对接口变更的审计和回溯特别有价值。最后是脚本系统。很多人担心这种小体积工具写不了复杂断言其实 Bruno 的脚本层是完整的 JavaScript 运行时支持请求前脚本和响应后脚本能通过bru.setVar()动态写环境变量也能用assert对响应体做判断。上一轮测试的结果可以传给下一轮请求做登录态串联、Token 提取、断言校验都没有问题。这部分能力我会在第三章实操里展开写。3. 从安装到迁移一步步把 Postman 替换掉3.1 安装与首次启动十秒内进入工作状态Bruno 的官网会在首页直接给你三个平台的下载入口同时也提供 GitHub Releases 页面适合想下载指定版本的开发者。这个细节对团队内部统一版本很有用不像我用 Postman 时经常被自动更新打个措手不及。Windows 上直接下载 MSI 安装包双击一路 Next 就行安装完不会要求重启也不会往开始菜单塞一堆东西。macOS 用户拿到是 dmg 文件拖进 Applications 即可。Linux 用户的选择多一点有 AppImage、deb 包和 snap 包。我在 Ubuntu 上的安装方式很直接去 Releases 页面下载.AppImage文件然后两条命令搞定chmod x Bruno-*.AppImage ./Bruno-*.AppImage如果你想用 deb 包下载后执行sudo apt install ./Bruno-*.deb也可以。安装包很小整个过程基本不用等待。首次启动没有登录页没有“Get Started”引导流程打开就是一个干净的集合列表。我做了个小测试从双击图标到界面完全可交互大概 1 秒出头。这个启动速度真的会影响使用习惯以前我用 Postman 是“批量启动回复完消息再回来发请求”现在是想起来一个接口要测随手就点开了。界面默认是英文但不构成障碍因为核心按钮和布局非常直观。如果你实在不习惯英文界面可以留意一下社区汉化包或者等官方后续的多语言支持。我在实际使用中觉得工具顺手比“中文界面”更重要请求编辑器里多的也是你自己的 JSON、变量名和脚本界面英文认几次就熟了。有一点要注意第一次安装后建议先新建一个空集合确认应用的本地工作目录能正常创建。Bruno 的集合本质是文件夹如果你所在的系统对某个目录没有写权限后续保存请求时会报错。默认情况下它会放到用户目录下一般不会有什么问题。3.2 建集合、发 POST 请求、用环境变量跑通日常打开 Bruno 的第一件事我建议从左边的 Collection 面板新建一个集合。点击 “New Collection”给它取个名字比如“商城后端接口”。创建后你会在本地文件系统里看到一个以集合名命名的文件夹里面之后会存所有请求文件。在集合下新建一个 Request选择方法为 POST。日常写接口POST 用的频率不比 GET 低而 Postman 新用户最容易卡住的地方就是选完 POST、写完 URL却发现请求体不知道填在哪。Bruno 的界面布局非常清晰请求地址栏下面是标签页有 Params、Headers、Body、Script、Docs 等分区。在 Body 标签里选择 JSON 格式然后直接粘贴请求体内容{ username: admin, password: 123456 }请求头方面如果接口需要鉴权可以在 Headers 标签里加Authorization: Bearer xxxxxx。更规范的做法是把 Token 放到环境变量里在请求头引用变量。Bruno 支持在右上角管理 Environment点击图标可以创建 dev、test、prod 等环境每个环境里配置键值对比如baseUrl: http://127.0.0.1:8080 token: eyJhbGciOiJIUzI1NiIs...然后在请求 URL 里写{{baseUrl}}/api/v1/login这样切换环境时URL 会自动指向不同服务器不用手动改地址。环境变量和集合变量都可以在脚本中动态修改极大地提高了联调效率。我从 Postman 迁过来时最担心的就是对这套“大括号变量”语法的支持实测发现 Bruno 和 Postman 几乎一致都是{{变量名}}集合文件导入后基本不用改 URL。日常调试属于高频操作我实际体验下来Bruno 的点按响应时间比 Postman 流畅得多。原因是它不需要先过一层工作区逻辑请求直接发出去响应直接回来整个过程没有多余环节。发送请求的按钮大而明显响应区支持 JSON 高亮和折叠查深层字段时很方便。3.3 提取返回值和断言脚本能力一点不缩水很多人用 Postman 的习惯是先发一个登录接口然后手动复制返回的 token粘到后续请求的 Headers 里。这种方式偶尔调一两个接口还行调试大量接口时效率很低。正确的做法是用脚本提取返回值自动写入变量后续请求自动引用。我在 Bruno 里的做法是在登录请求的 Script 标签里增加响应后脚本const data res.body; if (data data.data data.data.token) { bru.setVar(token, data.data.token); }第一行拿到响应体第二行判断是否存在 token 字段存在就写进环境变量。以后任何请求只要 Header 里使用Authorization: Bearer {{token}}就会自动携带最新 token。这套逻辑和 Postman 的pm.environment.set(token, ...)是同一个思路只是前缀从pm.换成了bru.迁移成本很低。断言也对标了测试框架里最常用的方式Bruno 内置assert对象。比如校验登录接口是否成功我一般写三行assert.equal(res.status, 200); assert.equal(res.body.code, 0); assert.ok(res.body.data.token, 响应中应有 token 字段);第一行检查 HTTP 状态码第二行检查业务状态码第三行检查关键字段是否存在。断言失败时请求结果会标记为失败CLI 跑测试时也会以非零码退出方便 CI 判断。还有一种常见需求是检查响应时间比如接口必须在 500ms 内返回可以这样写assert.ok(res.responseTime 500, 响应时间应小于 500ms);Bruno 的 Script 分区同时支持请求前脚本和响应后脚本所以可以做签名、加时间戳、动态生成请求体等操作并不只是简单发请求。对大多数团队的业务场景来说这套脚本能力已经足够覆盖日常和自动化测试的需要。3.4 导出 curl、导入 Postman 集合与团队共享很多人在搜“Postman 怎么导出 curl”因为要给同事或者在命令行里复现接口问题。Bruno 保留了这个高频能力每个请求都有复制为 curl 的菜单项点一下就能得到可直接在终端执行的命令。我在排查线上问题时经常这样用先在 Bruno 里调通然后复制 curl 去服务器上执行验证网络链路或者绕过本机代理干扰。更重要的迁移能力是 Postman 集合导入。Bruno 支持直接导入从 Postman 导出的 JSON 集合文件。你只需要在 Postman 里把集合导出为 JSON然后在 Bruno 中点击 Import选择文件集合里的请求目录、URL、Headers、Body 都会保留下来。我导入一个 40 多个请求的接口集合只花了几秒钟整体还原度比较高。但也不是完全没有差异有两点需要留意。第一Postman 里如果使用了动态变量或者较复杂的脚本导入后脚本部分不一定 100% 兼容。因为 Postman 脚本基于pm.*APIBruno 的脚本 API 是bru.*加assert二者需要手动改写。不过好消息是如果你原来的脚本只做简单断言代码量很少改起来也就几分钟的事。第二Postman 集合里有 folder 的层级关系Bruno 也会保留但如果某个请求依赖 Postman 的全局/集合级变量Bruno 导入后需要在环境变量里手动补一下。迁移时我建议把 Postman 的环境变量一并导出至少对照着抄一遍否则会出现 URL 里变量无法解析的问题。团队共享方面Bruno 的思路是把集合目录提交进 Git 仓库。每个.bru文件都是纯文本格式团队成员 pull 下来就是最新接口集合。没有云端同步的延迟没有“我改了你怎么看不到”的问题。同样别人改完提交上去你git pull就能拿到。我在团队里把这个流程跑了快一个月项目经理和测试同事都觉得很直观接口变更直接在仓库里看 diff 就行。4. 自动化测试与持续集成把“替代品”用成生产力4.1 用命令行跑自动化测试轻量不代表只能手动点按钮。Bruno 官方提供了命令行工具usebruno/cli安装后可以让同一套接口集合跑成自动化测试并且输出多种格式的测试报告。这一步直接解决了我对“替代品能不能接 CI”的核心疑虑。安装 CLI 很简单前提是本机有 Node.jsnpm install -g usebruno/cli然后在集合根目录初始化配置文件。Bruno 使用bru.json来声明测试入口和环境变量文件一个典型的配置是这样的{ version: 1, name: shop-api-tests, type: collection, ignore: [node_modules, .git] }接着在集合目录下运行bru run . --env Test它会递归执行集合目录下的所有请求和脚本断言终端会把每个请求的通过/失败情况打出来。如果你想要 JUnit XML 格式的报告用来对接 Jenkins 或其他 CI 平台加一个参数bru run . --env Test --output-format junit --output-dir ./reports此外它还支持 HTML 报告用浏览器打开可以直接看到每个用例的执行时间和断言结果给测试同事看非常直观。我实际跑了一个 50 个请求左右的接口回归集包含登录串联、数据增删改查、权限校验整体跑完就几秒到十几秒比之前用 Newman 跑同样的用例要快不少毕竟没有那一层应用加载开销。需要说明的是CLI 跑测试和你手动点按钮用的是同一套.bru文件也就是说测试代码和接口定义是同步的。手动调试时改了一个断言自动化测试也会跟着变两边不会出现“本地能过CI 跑失败”的版本漂移问题。4.2 在 CI 里落地Git 同步 CLI 回归把 CLI 接进 CI 是我这几周做的最有价值的一件事。以前团队的接口回归靠测试人员手动在 Postman 里点 Collection Runner容易漏跑而且每次跑完还得人工截图汇报。现在直接把回归测试放进流水线每次代码合并前自动跑一遍。以 GitHub Actions 为例我写的工作流大致长这样name: api-regression on: pull_request: paths: - backend/** - api-tests/** jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm install -g usebruno/cli - run: cd api-tests bru run . --env Test --output-format junit --output-dir ./reports - uses: actions/upload-artifactv4 with: name: api-test-report path: api-tests/reports这套流水线的好处是零额外服务成本。集合文件已经在 Git 仓库里CI 只需要安装一个 npm 包里代理的 CLI就能跑全部测试。跑完生成的 JUnit 报告可以用 Publish Test Results 等 Action 直接展示在 PR 页面上谁改坏了接口一目了然。如果你用的不是 GitHub而是 GitLab CI流程也是同一套路在.gitlab-ci.yml里加一个 stage安装 CLI跑bru run把报告作为 artifact 上传。CLI 本身跨平台Linux runner 上跑完全没问题。我踩过的一个坑是如果集合里的请求依赖浏览器层面的能力比如 WebSocket或者必须在有界面的环境里跑纯 CLI 模式可能受限。但大部分 HTTP 接口自动化场景不受影响。初期接触 CI 的同事可能会忽略环境变量文件安全问题注意不要把包含生产环境的密钥的集成环境文件提交进仓库建议用.env忽略规则或者通过 CI 的 Secret 机制注入变量。5. 迁移路上的常见问题与排查技巧实录5.1 踩坑速查表我把自己从 Postman 迁移到 Bruno 这一路上遇到过的典型问题整理成了一张速查表。这些问题有的来自网上社区有的是我实际踩过之后才排查明白的按这个顺序看能帮省不少时间。问题现象可能原因解决办法导入 Postman 集合后 URL 出现未替换变量环境变量没有一并导入手动在新工具中重新创建 dev/test/prod 环境变量响应后脚本执行报错脚本中用到 Postman 的 pm.* API改为 bru.* 或 assert稍作兼容处理bru run提示找不到命令CLI 未正确安装执行npm install -g usebruno/cli并确认 Node.js 版本在受支持范围内请求能发但断言一直失败响应体结构与断言写的不一致先用console.log(res.body)打印响应原始数据再核对字段路径自签名 HTTPS 证书无法访问校验证书失败在集合设置里调整 TLS 校验策略或把环境变量配置为忽略证书错误中文界面缺失官方暂未内置多语言可查社区汉化包如果必须用中文先确认团队统一版本后再引入汉化文件集合文件提交到 Git 之后其他成员打不开未安装对应版本或缺少依赖在仓库 README 中写清推荐版本和安装命令尽量让团队统一工具版本浏览器版 Hoppscotch 无法访问本机接口浏览器跨域限制同类场景建议使用本地客户端线上地址可以临时改用 CORS 代理这里面我想重点提一下“签名证书校验”的问题。很多公司内部测试环境用的是自签名 HTTPS 证书Postman 会在首次访问时弹窗问你是否信任。Bruno 默认行为会严一些第一次遇到自签名证书可能直接报错。处理方法不是在系统层关掉所有证书校验而是在集合级别把 TLS 校验策略改成不完全校验或者把证书导入系统信任链。推荐后一种更安全。另外一个容易被忽略的是环境变量文件的管理。Bruno 虽然把集合文件以文本形式存到本地方便 Git 管理但环境变量里很可能有数据库密码、内部密钥这类敏感信息。提交代码前一定要看清楚哪些文件进了.gitignore别把生产环境的密钥推到仓库里。我在团队里就把.env文件和包含敏感值的 environment 文件统一忽略只有线上流水线通过 Secret 注入这个习惯建议从一开始就建立。5.2 我从 Postman 迁移过来的几点心得最后说几点个人体会不算教程就当按时间顺序踩坑后的复盘。不要指望所有东西一次迁完。我从 Postman 迁到 Bruno 不是一口气把几十个集合全搬过去的而是先挑了一个核心业务模块的集合做试点。先把请求、环境变量、断言跑通团队成员试用了两天觉得顺手了再逐步扩大迁移范围。这样心理压力小也方便在早期发现问题。脚本改写要趁早规划。Postman 的老脚本如果依赖pm.environment、pm.test、pm.expect这些 APIBruno 不会自动翻译。我的办法是提供一个简单的对照表让团队成员照着改Postman 写法Bruno 写法pm.environment.set(token, value)bru.setVar(token, value)pm.test(名称, function(){...})assert.equal(...)pm.response.to.have.status(200)assert.equal(res.status, 200)pm.variables.get(varName)bru.getVar(varName)对应关系其实很直白老手十分钟就能摸清规律。just note 很多时候需要调试脚本里加console.log在 CLI 或 GUI 的响应输出中查看中间变量值比闷头改快得多。轻量工具不等于只能做“轻量事”。以前我会惯性认为自动化测试和 CI 集成这种重活必须依赖 Postman NewmanBruno 这一套组合拳打完我发现真正决定工具上限的不是安装包大小而是数据模型和脚本能力。文件即接口、CLI 即测试引擎这套设计让 10MB 的工具也能扛起自动化回归的重担。我个人现在的工作流是开发阶段用 Bruno 调接口写脚本时把它当轻量 IDE 用提 MR 前用 CLI 跑一遍全量回归CI 里再自动跑一次报告直接推到 MR 评论区。整个过程没有打开过大的 Electron 应用不需要账号登录资源占用不到以前的零头。最后再分享一个实际操作中的习惯我会在集合目录里维护一个README.md把项目里共有哪些环境、如何运行测试、常见问题挂在哪都写进去。因为集合文件现在就躺在 Git 仓库里后续接手的人打开目录就能看到全部说明不用再去文档站找入口。这个习惯让接口测试的门槛明显降低新同事上手也快了不少。