最近我把用了好几年的 Postman 换掉了。不是它不好而是它实在越来越重。如果你也经历过打开 Postman 要等好几秒、明明只是调个接口却被强制登录卡住、项目里旧集合越堆越多每次加载都在转圈的场景那你大概能明白我为什么看到“10MB 安装包、启动不到 1 秒”这种描述时会瞬间来了兴趣。这说的是一款开源免费的 API 调试工具不需要账号、不需要登录数据全部存在本地文件里用起来有点像轻量版的 Postman但整个设计思路完全是另一条路子。对做接口联调、自动化测试、甚至想把 API 请求纳入 CI 流水线的开发者来说它很值得认真看一眼。我实际用了大概一个月把大部分接口调试工作都搬了过去。这篇文章就从头讲清楚它解决了什么问题、核心能力够不够用、怎么从 Postman 平滑迁移以及我在过程中踩过的坑。1. 为什么我决定从 Postman 换到轻量工具1.1 Postman 越来越重的几个真实痛点先说结论Postman 仍然是功能覆盖最全的 API 调试工具之一团队协作、接口文档、Mock Server 这些能力都非常成熟。但对我这种日常主要做后端接口调试、自动化回归、偶尔帮前端对接口的人来说有几个痛点越来越让人难受。第一是启动速度和体积。Postman 的安装包已经来到几百 MB 级别底层是 Electron 套壳冷启动在普通笔记本上经常要 3 到 5 秒。我电脑配置不算差但打开 Postman 后切到某个集合偶尔还是要等它重新渲染列表。一次两次还好一天打开几十次积攒下来的等待感真的很消磨耐心。第二是强制登录和账号体系。新版 Postman 不登录基本没法用登录后又默认把集合、环境变量往云端同步。好处是跨设备方便坏处是你所有的接口请求、Header 里的 token、甚至一些内部测试数据都存在别人家的服务器上。对很多公司来说这本身就过不了信息安全那关。于是你会看到团队里有人专门找“免登录版本”本质上都是在绕开这套账号机制。第三是免费版和付费墙的边界越来越明显。单机使用还好但只要涉及到团队协作、共享集合、运行测试报告、持续集成这些高级能力基本都要上付费团队版。对于一个小团队或者个人开发者来说这笔钱花得不痛不痒但总归是个约束。第四是功能膨胀带来的复杂度。Postman 的界面已经不止是“发请求、看响应”了左侧是集合、环境、Mock、文档、监控、团队协作顶部还有一堆入口。对重度用户这是效率对只想调个接口的人这是负担。1.2 “轻量”不只是体积小更是一套理念一开始我以为“10MB 替代品”只是个玩笑用过才发现它轻的不只是安装包而是整套设计理念。这款工具没有账号体系打开就能用。数据存储采用“文件即集合”的方式每一个请求、每一个环境配置都是一个纯文本文件项目目录里天然就是一套完整的 API 集合。这意味着你的接口定义可以用 Git 管理每一次改动都清清楚楚代码评审时可以直接看 diff。相比之下Postman 的集合是存在云端或本地数据库里的很难做版本管理。这种“本地优先”的思路带来的直接好处是启动快、不依赖网络、隐私安全。没有后台同步线程在跑没有登录态要刷新没有云服务要探测客户端就只做一件事把文件里的请求加载出来发出去展示响应。所有的复杂度都让位给了核心功能体积和速度自然就降下来了。所以如果你只是因为“小”才关注它其实还没抓到重点。它的真正价值是让 API 集合回归到了开发者熟悉的“文件 Git 命令行”工作流里让接口测试这件事变得更透明、更可控。2. 这款替代工具的整体设计与核心能力2.1 为什么它可以把体积和启动速度做到这个级别在聊工具选型之前先看一张我手头环境里的对比表。数据不保证绝对严谨但都是实际使用中的体感差别之大足以说明问题。指标Postman v10轻量替代工具InsomniaHoppscotch安装包体积几百 MB10MB 级别100MB 左右无安装包浏览器 PWA冷启动体验3-5 秒偶发卡顿1 秒以内1-2 秒打开浏览器即用内存占用空闲300-500MB60-100MB150-300MB取决于浏览器是否需要登录强制不需要可选不需要数据存储位置云端 本地本地文件本地本地浏览器为什么能做到这个差距关键不在于它是用什么语言写的而在于“去掉了什么”。Postman 的启动链路里有账号认证、云同步、工作区加载、多用户权限判断等一大堆逻辑这些都要消耗时间和资源。而这个替代工具直接把云服务拿掉了客户端启动时只需要读取本地目录里的请求文件渲染树形结构然后待命。你可以理解成 Postman 是“带厨房、餐厅、外卖配送的饭店”而这个工具是“一个灶台一口锅”你要炒菜它立刻能开火但它不会帮你送外卖。2.2 核心功能盘点日常接口调试完全够用先不用急着担心“替代品”功能缩水。我梳理了一下日常开发中最高频的接口调试需求它基本都覆盖了。请求构造支持 GET、POST、PUT、DELETE、PATCH、HEAD 等常见方法支持 URL 参数、Headers、Body。Body 支持 JSON、XML、表单form-urlencoded、multipart/form-data 和纯文本文件上传也没问题。环境变量可以建立多个环境dev、test、prod每个环境里定义变量然后在 URL、Header、Body 中用{{variable}}的方式引用切换环境只需点一下。集合管理多个请求归入一个集合集合支持子文件夹可以整体运行。脚本能力请求发送前可以执行前置脚本发送后可以执行后置脚本和断言。脚本语法是 JavaScript写过 Postman 的人基本能零成本上手。命令行与 CI有配套的命令行工具可以在终端里直接跑集合测试输出 JSON 格式测试报告很适合接进 GitLab CI 或 GitHub Actions。导入导出支持导入 Postman 的 Collection v2.1、OpenAPI 3.0、cURL 命令也支持导出 cURL迁移路径很顺。这些能力覆盖了日常接口调试、联调、自动化冒烟测试的绝大多数场景。唯一明显弱于 Postman 的是“在线文档分享”“Mock Server”“云端协作”这些偏平台化的功能但如果你只是想找一个本地为主的工具完全够用。3. 上手实操从零开始完成一次接口调试3.1 安装与首次启动安装没什么可说的到官网或 GitHub Releases 下载对应平台的安装包。Windows 是 exemacOS 是 dmgLinux 有 AppImage 和 deb 包。整个安装过程非常快几乎没有存在感。装完后双击打开体感上就是“秒开”连启动画面的等待感都没有。这年头连很多文本编辑器都做不到这种启动速度放在一个 API 调试工具身上确实有点反差。首次打开不需要注册、不需要登录、不需要激活。界面左侧是集合列表中间是请求编辑区右侧是响应区顶部是环境选择器。整体和 Postman 的布局逻辑很像所以从 Postman 迁移过来的用户几乎不需要学习成本唯一要适应的其实是它的“项目”概念在它眼里一个文件夹就是一个项目你打开后直接用这个文件夹里的集合。3.2 创建第一个请求登录接口实战我们拿最常见的场景来演示登录接口拿到 token再带 token 请求用户信息。第一步新建集合。点左侧的“New Collection”命名成“用户服务”。建好集合后在集合下新建请求命名“登录”。请求方法选 POSTURL 填{{base_url}}/auth/login。第二步配置环境变量。左侧切到 Environment 标签新建一个 dev 环境添加两个变量变量名示例值base_urlhttp://localhost:8080usernametest_userpassword123456第三步编辑请求。在 Body 里选择 JSON 格式填入{ username: {{username}}, password: {{password}} }请求头里加上Content-Type: application/json。点发送响应区会展示状态码、响应头和响应体。如果是 JSON 响应会自动格式化查看嵌套结构很方便。这里有一个很实用的细节如果你要在别的工具或者命令行里复现同一个请求不需要手动拼。右键点击请求选择“Copy as cURL”它会基于当前环境变量把完整请求生成一条 curl 命令直接贴到终端就能跑。这个功能是我日常用得最多的调试完接口直接丢给同事省去口述参数。3.3 自动化的灵魂脚本断言与数据流转Postman 之所以强大不只是因为它能“手动发请求”更在于它能把一串请求串成一条测试链路。这个替代工具的脚本能力虽然 API 不一样但逻辑很像核心写法是这样。先看前置脚本。行的用法是在发送请求前执行可以动态改 Header、改 Body、设置变量。比如现在大多数接口都需要带 Authorization我不想在每一个请求里手动粘 token可以在前置脚本里这样写const token bru.getEnvVar(token); if (token) { req.setHeader(Authorization, Bearer token); }这样只要请求在发送前读一下代码发现环境里有 token 就自动加到 Header 里所有请求都通用。再看后置脚本也就是登录请求返回后要做什么。登录接口返回的 JSON 大概是这样的结构{ code: 0, message: success, data: { token: eyJhbGciOi..., userId: 10086 } }在后置脚本里我们可以断言请求成功并把 token 和 userId 提取到环境变量里assert(res.status 200, 登录接口应该返回 200); const data res.body; assert(data.code 0, 业务 code 应该为 0); assert(data.data data.data.token, 响应里应该有 token); bru.setEnvVar(token, data.data.token); bru.setEnvVar(userId, data.data.userId);这段脚本跑完之后环境变量里的 token 和 userId 就被自动更新了。此时再去看“用户信息”接口它的前置脚本自然会从环境变量里取出新 token 带上完全不需要手动干预。这就在工具内部形成了“登录 → 拿 token → 调下一个接口”的链路跑集合时可以一口气全走完。这里要特别说明一下断言语法test()和assert()都是全局可用的函数。test(描述, () { ... })用来组织测试用例assert(条件, 失败时的提示)用来判断。如果你之前写过 Jest会觉得很眼熟。3.4 一键跑集合批量运行和 CI 集成当集合里的请求多了以后你不可能一个一个手动点。集合运行器可以一次性按顺序执行集合内的所有请求并汇总测试通过情况。在集合右键菜单里选择“Run”选择环境点运行工具就会按顺序把集合里的请求全部发一遍。每条请求有没有断言失败有哪些请求超时界面上一目了然。我一般会在联调前跑一遍集合能提前发现很多低级问题比如某个接口 SQL 报错、某个字段拼错、某个服务没启动。更进阶的玩法是通过命令行工具执行。安装对应的 CLIbru后在项目目录下直接运行bru run --env dev它会读取当前目录下的集合文件按顺序执行所有请求然后在终端里输出测试结果。如果配合--format json还能生成机器可读的报告。这意味着你可以把它集成到 CI 里比如在代码合并前自动跑一遍核心接口回归。这一步我在迁移前也没想到等真正跑起来才发现Postman 需要付费才能开放给 CI 的能力在这款轻量工具里是默认就有的。4. 从 Postman 迁移的完整指南4.1 一键导入已经成熟但环境变量要花点功夫从 Postman 迁移最担心的就是历史资产搬不过来。实际试下来集合迁移比你想象中顺利在 Postman 中右键集合选择“Export”导出格式选 Collection v2.1得到 JSON 文件。然后在替代工具的菜单里选择“Import”指向这个 JSON集合和请求基本可以完整导入。需要注意两个地方第一Postman 导出时会附带请求中的 URL、Headers、Body这些一般没问题但环境变量不会跟着集合一起导出。Postman 的环境变量是在 Environments 里配置的导出集合时并不包含它们。我的建议是直接在替代工具里手动重建一遍环境通常也就十几个变量几分钟能搞定。第二集合里的请求如果大量使用了 Postman 内置变量比如{{$guid}}、{{$timestamp}}或者依赖pm.collectionVariables这种作用域导入后这些不会自动转换需要手动改成目标工具支持的写法。好在实际开发里我们用的变量大多是自定义的影响不大。4.2 脚本迁移从 pm.* 到 bru.* 的对照思路这是迁移过程中最需要花时间理解的部分。Postman 的脚本模型建立在pm全局对象上而替代工具提供了bru、req、res等内置对象。直接看对照表最快用途Postman 写法替代工具写法获取环境变量pm.environment.get(key)bru.getEnvVar(key)设置环境变量pm.environment.set(key, value)bru.setEnvVar(key, value)请求头设置pm.request.headers.add({ key, value })req.setHeader(key, value)获取响应体 JSONpm.response.json()res.body获取状态码pm.response.coderes.status断言pm.test(描述, () { pm.expect(...) })test(描述, () { assert(...) })有几个容易被忽略的差异。res.body在对方工具里是已经解析好的对象吗实测下来如果响应是 JSONres.body已经是对象了可以直接res.body.data.token这样取字段不需要再调JSON.parse()。另外assert的第二个参数是失败提示如果你断言失败了它会显示你写的提示信息写清楚一些对排查问题很有帮助。4.3 团队协作从云端工作区切换到 Git 工作流迁移后感触最深的变化是团队协作方式从“云工作区”切换到了“Git 仓库”。之前用 Postman 做团队协作不开付费版的话靠的是导出 JSON 文件发来发去很容易出现版本不一致。开了付费版会好一点但工作区里的很多东西依然像个黑盒改动记录不够直观。现在集合就是文件每个请求一个.bru后缀的文本文件团队约定一个仓库专门放 API 集合大家通过 MR 提交变更Review 时可以看每一个请求的改动 diff。接口多了或者字段改了直接在文件里搜索替换比在图形界面里一个个点高效太多。CI 脚本也可以直接从这个仓库拉代码跑集合测试一套流程走下来接口回归从“人肉点击”变成了“自动执行”。5. 常见问题与避坑实录5.1 导入 Postman 集合后请求顺序乱了Postman 集合里的请求顺序依赖它自己的排序逻辑导入到替代工具后偶尔会出现顺序错乱。解决办法有两个一是导入后在集合里手动拖动调整顺序二是在集合运行前确认需要串行的请求比如登录 → 鉴权请求之间的脚本逻辑已经写对了因为真正跑自动化时脚本链路比 UI 顺序更关键。如果某条请求依赖前一条的返回值不要靠“人工按顺序点”要在后置脚本里把数据存到环境变量这才能保证批量运行时顺序没问题。5.2 断言脚本一直不生效这是我初期踩得最多的坑。新手容易把断言写到前置脚本里结果请求还没发出去就开始断言必然失败。要注意区分前置脚本区域写的是请求前逻辑比如设置 Header、设置变量后置脚本区域写的是响应回来后的逻辑比如状态码断言、字段校验、提取数据。放错位置是最常见的“不生效”原因。另外环境变量作用域也要注意。bru.setEnvVar设置的环境变量是当前环境级别的如果你在集合运行前手工切换了环境脚本写入的变量只对当前环境生效。批量运行时建议一开始就明确指定环境参数避免跑着跑着变量指向了错误环境。5.3 接口是自签名证书或内网地址请求报证书错误开发环境里很多人会用自签名 HTTPS 证书或者内网 IP 地址这时请求经常报证书校验失败。解决办法不是关掉系统校验而是在工具设置里找到 SSL 证书校验相关的选项单独针对当前请求或当前环境关掉校验。如果公司有自己的 CA 证书也可以直接把证书文件添加进工具让客户端信任内部证书。5.4 内存占用和性能实测记录最后放一组我实际观察的数据覆盖了我最常使用的两种场景。这个工具在我常用的三台设备上表现很一致空闲时内存占用在几十 MB 级别打开一个包含几十条请求的集合跑了完整一轮回归后内存增幅也非常有限。对比 Beats Postman 动不动就上 300MB 的内存占用量很多情况下完胜尤其适合那些开发机内存只有 16GB、还同时开着 IDE 和浏览器的同学。使用场景Postman 实测内存替代工具实测内存空闲挂后台320MB78MB跑完含 30 个请求的集合410MB96MB这里也想提醒一句不同版本的性能差异比较大如果你试用时发现某个版本内存偏高优先升级到最新版优化一直在持续推进。最后说点个人体会。我并不是建议你把 Postman 彻底卸载毕竟在生成文档、分享接口、多人协作这些场景里它依然是很多团队的首选。但如果你和我一样日常核心诉求是快速验证接口、跑自动化回归、把接口定义纳入代码仓库统一管理那这个 10MB 级别的小工具完全值得一试。我目前的做法是新项目一律用轻量工具管理集合老项目逐步迁移Postman 只保留给必须要用团队协作者的场景。先拿一个小集合迁移过去跑一遍你会发现原来被臃肿工具拖慢的工作流居然可以这么轻快。