面对 Postman 越来越臃肿的安装包、越来越慢的启动速度，还有动不动就弹出来的登录提醒，我相信不少接口测试的老手心里都憋着一股火。我自己的电脑上，Postman 从双击图标到真正能输入 URL，慢的时候能转七八秒的圈，这还是在 NVMe 固态硬盘上。直到我花了一个周末折腾了一圈开源工具，最后锁定了这个安装包只有 10 MB 左右、冷启动不到 1 秒的轻量级替代品，才算是把这块心头病给治好了。
这篇文章不是要劝你立刻卸载 Postman，而是想从一个实际干活的人角度，聊聊这个轻量替代品到底是什么、它凭什么能做到这么小这么快、以及我把它接入日常工作流之后的真实体验。如果你正被 Postman 的内存占用和启动速度折磨，或者团队里想找一套更贴近 Git 工作流的接口管理方案，这篇文章应该能给你一些参考。
1. 为什么我开始嫌弃 Postman，以及 10MB 替代品到底是个什么来头
先交代一下背景。我日常主要做服务端接口开发和联调，Postman 从 7.x 版本用到现在，说句公道话，它的集合管理、环境变量、自动化测试这些功能确实成熟，生态也完善。但最近一年，我是越来越觉得它不对劲。
首先是体积和资源占用。Postman 现在的安装包动辄几百 MB，装完之后的缓存、索引、GPU 加速进程，在任务管理器里一看，内存占用轻轻松松上 1GB。我笔记本只有 16GB 内存，平时要开 IDE、数据库客户端、浏览器一堆标签页，再挂个 Postman，内存直接见红。其次是启动速度，哪怕是 10.13.6 这种新版本，冷启动也得等好几秒，中间那个 Loading 动画看得人着急。最让我烦的是强制登录和账号体系，偶尔离线环境下想临时测个接口，它还要你登录，甚至有时候登录态过期了，直接卡在登录页面进不去。
所以我当时给自己提了个需求：找一个接口调试工具，启动要快、体积要小、最好不用登录、数据要能本地管理。后来逛 GitHub 的时候发现了这个方案——一个基于本地文件存储的 API 客户端，安装包不到 11MB，打开速度体感就是秒开，界面风格和 Postman 很像，但核心设计思路完全不同：它以文件夹和 Markdown 文件的形式保存每一个请求，整个项目就是一个纯文本目录，天然适合用 Git 做版本管理。
这个工具目前在国内外的开源社区热度都很高，很多团队把它当成 Postman 的轻量替代方案来用。它的核心优势总结下来就三条：一是底层基于 Web 技术但打包优化做得极其克制，所以安装包能压在 10MB 出头；二是启动时不加载远程资源、不做遥测同步，所以冷启动速度飞快；三是请求数据就是本地文件，不锁库，不绑定账号，完全归你掌控。
2. 安装部署与第一个请求：从下载到发请求只要三分钟
2.1 下载安装的那点事儿
我是直接在 GitHub Releases 页面下载的对应自己系统的安装包。以 Windows 为例，下载下来的安装包大概 10.6MB，和其他动辄几百 MB 的“全家桶”比起来，简直像是一个轻量级工具该有的样子。安装过程走的是系统安装器，一路 Next 就行，没有额外组件、没有后台服务、没有开机自启的常驻进程。
装完之后我又特意看了一眼安装目录，整个安装文件夹加起来也就 40MB 多一点点。你们要知道，Postman 的安装目录随便都是 500MB 往上走的。这里顺便提一句，官方也提供了免安装的 zip 压缩包，解压即用，适合放在 U 盘或者公司电脑上临时用。但这个我没实际用过，因为我觉得还是正常安装版体验更完整。
Linux 环境下也有对应的 AppImage 或者其他发行版打包格式，Ubuntu 用户可以直接拉取仓库安装，不需要像 Postman 那样手动配环境或者担心依赖缺失。如果你平时在服务器上做开发，完全可以把请求集合的文件夹放到服务器上，随手就能改、随手就能发。
2.2 创建第一个请求时，我发现的细节
打开软件之后，界面布局和 Postman 很相似，左边是请求集合列表，中间是请求编辑区，右边是响应区。新建请求的时候它会问你存到哪个集合里，这点和 Postman 操作逻辑是一样的。
我随便填了一个测试接口的 URL，选好 GET 方法，点 Send，响应几乎瞬间就回来了。虽然响应快主要归功于网络和服务端处理速度，但工具本身的 UI 响应也很跟手，不像 Postman 在高分屏下偶尔会有明显的输入延迟。
有一个细节让我挺舒服：新建请求时默认的请求文件名就是请求的描述内容，比如我填了"查询用户信息"，文件名就是"查询用户信息.bru"。这个 .bru 文件是个纯文本格式，用文本编辑器打开就能看到完整的请求配置，包括 method、url、headers、body 等等。熟悉 Postman 的你大概已经意识到这意味着什么了——它完全可以像管理代码一样管理接口定义，每次修改都能通过 Git diff 一眼看出改了哪些字段。
提示：这个 .bru 文件格式是纯文本，但如果团队里有人不太熟 Git，建议还是先在 IDE 里装好相应的语法高亮插件，避免有人直接改坏了文件格式。
2.3 导入 Postman 旧数据迁移
从 Postman 迁移过来最关心的就是历史数据能不能带过来。它支持直接导入 Postman 导出的 JSON 集合文件，我在 Postman 里选中已有的集合，右键导出为 v2.1 格式的 JSON，然后在替代工具里选择导入，瞬间所有请求和历史环境配置就都进来了。注意，我这里说的是集合本身，如果 Postman 里那些用脚本动态生成 headers 的预请求脚本，导入进来之后可能需要手动整理一下，毕竟两者的脚本语法都是基于 JS 的，但执行时机和内置 API 略有差异。
第一次导入完我特意抽查了几个带认证 token 的接口，发现请求头、query 参数、路径参数基本都能完整迁移。不过 Postman 的 CryptoJS 写的 HMAC 签名脚本，还是得自己重新翻译成新工具支持的脚本写法，这个后面专门讲。
3. 核心细节解析：集合、环境变量和脚本这三个基本功到底怎么样
3.1 集合的概念变成了真实文件夹
在 Postman 里，集合（Collection）是一个虚拟概念，数据存在 Postman 自己的索引里，你看不到它的物理存储结构。而这个替代工具把集合直接映射为文件系统里的真实目录，每一个请求就是一个 .bru 文件，目录层级就是集合的嵌套分类。
这意味着你可以用文件资源管理器直接拖拽调整请求位置，也可以在 IDE 里批量替换某些请求的 URL 前缀。更实用的是，代码评审的时候，可以直接在 GitLab 或 GitHub 上打开某个请求文件，看它的完整配置，不需要把工具打开再去翻找。
我在实际项目里就把接口集合的目录和项目代码放在同一个仓库里，前端、后端、测试共用一套接口定义。任何人改了接口，提交代码的时候自动带上 .bru 文件变更，Review 的人一眼就能看出接口改动是否同步更新了调试文档。这一点是 Postman 那种中心化云同步模式做不到的——它要么靠团队在 workspace 里协作，要么得导出文件再传，远没有 Git 天然分支管理来得顺滑。
3.2 环境变量用起来和 Postman 差不多，但有个坑
环境变量这个东西，做接口测试的人每天都离不开。开发环境一个 base URL，测试环境一个 base URL，有时候还有本地环境、预发布环境，全靠环境变量来切。
这个替代工具的环境变量配置方式和 Postman 类似：先创建环境，再在环境里配置键值对，请求的 URL 里用双花括号语法 {{baseUrl}} 来引用变量。不过它有一个和 Postman 不一样的地方——除了环境级变量，它还支持直接在集合级别定义变量，而且优先级是请求文件里的变量定义大于集合变量、大于环境变量。
初学时最容易踩的坑就在这：如果你在一个集合里定义了名为 baseUrl 的变量，又在环境里也定义了同名变量，很可能你以为切换环境能改变 baseUrl，实际上请求却一直走集合变量的值。我一开始就被这个现象迷惑过，排查了半天才发现是变量优先级的问题。
注意：使用共享变量名之前，一定先确认当前请求的 Variables 标签页是空白的。否则环境切到天边都没用，请求用的还是文件里写死的那份变量值。
3.3 脚本能力：从简单断言到动态签名
再来说说脚本。它支持在请求前（Assert/Script 标签页）写 JS 代码，也支持在响应返回后写断言脚本。基础用法和 Postman 的 Pre-request Script 以及 Tests 脚本很类似，常见的都有，比如：
- 从响应 JSON 里提取某个字段作为变量，供后续请求使用
- 发送请求前用环境变量拼接出时间戳或者随机数
- 对返回内容做断言，比如校验状态码、校验响应体的某个字段
但如果你在 Postman 里重度依赖了 require('crypto-js') 这类 Node.js 内置模块，那迁移的时候要注意了——这个工具的运行环境不是完整的 Node.js，很多内置模块是不支持的，它只支持浏览器端的 Web API 以及内置提供的一些轻量工具方法。我项目里有个老接口的鉴权逻辑是基于 AES 加密的，原本在 Postman 里用 CryptoJS 也就几行代码的事，迁移过来之后发现没有 crypto-js 模块，最后绕了一圈，用了 Web Crypto API 的 crypto.subtle 才实现了同样的 AES 加密。
如果你也有类似需求，我的建议是：先把 Postman 脚本里用到的外部依赖列个清单，然后逐个确认替代工具是否支持。如果有不支持又绕不过去的，优先考虑把它拆成一个独立的小服务，通过 HTTP 调用来生成签名，别硬在脚本里实现。
4. 实操过程：用这个工具跑通一个带完整鉴权和断言链路的接口测试
4.1 场景设定和预期目标
光说不练假把式。我拿一个实际项目举例：某内部管理系统的登录接口，逻辑是先获取一个带时间戳的签名，再用签名换取 token，最后带着 token 查询用户列表。这三个接口串起来就是一条完整的联调链路，用来验证工具在真实业务场景下到底能不能扛住。
我预期达到的目标有三个：第一，通过环境变量切换 dev 和 prod 两套环境的 base URL；第二，通过“接口间传递参数”的方式实现登录 token 自动写入后续请求的 header；第三，添加断言，确保每次请求返回的 HTTP 状态码和关键字段符合预期。
4.2 一步步操作的完整记录
第一步，创建一个集合，命名为 "用户中心联调"，在这个集合下新建三个请求，分别是"获取签名"、"登录换取token"、"查询用户列表"。每个请求的 URL 都用 {{baseUrl}} 开头，方便后续切环境。
第二步，创建两个环境，dev 环境设置 baseUrl 为 http://dev-api.internal.example.com，prod 环境设置 baseUrl 为 http://api.example.com。这里我故意用了 .internal 域名的样例，实际按自己公司环境配就行。
第三步，配置"获取签名"请求的响应后脚本。这个请求返回的 JSON 形如 {"data": {"sign": "xxxx"}}，我在脚本里写：
const body = res.body; const json = JSON.parse(body); bru.setVar("sign", json.data.sign);这里注意，bru.setVar 设置的是“运行时变量”，它不会永久写入环境配置文件，只在当前运行时有效。这正好是我想要的效果——签名这种一次性数据，根本不需要保存到环境里，每次运行时现取现用即可。
第四步，配置"登录换取token"请求。请求体里需要携带 sign 参数，我在请求体的原始 JSON 里直接写：
{ "appId": "123456", "sign": "{{sign}}" }发送前，工具会自动把 {{sign}} 替换成上一步脚本写入的运行时变量。登录接口返回 {"data": {"token": "eyJhbGciOi..."}}，我再在响应后脚本里写：
const json = JSON.parse(res.body); bru.setVar("token", json.data.token);第五步，配置"查询用户列表"请求，在请求头里加上：
Authorization: Bearer {{token}}这样当集合里的请求按顺序执行时，token 会自动注入，不需要手动复制粘贴。
第六步，给"查询用户列表"请求添加响应断言。我想要的是既校验状态码，又校验接口返回结构。在运行结果标签页里找到断言功能，填写类似这样的检查项：
expect(res.status).to.equal(200); expect(json.data.list).to.be.an('array');这里的断言语法和常用的测试框架类似，如果你已经熟悉 Postman 的 Chai 断言，上手基本没什么难度。
第七步，用"运行集合"功能把这三个请求按照顺序跑一遍。跑完之后能清晰地看到每个请求的通过/失败状态。断言的最终结果也一目了然。
4.3 运行机制和命令行的衔接
这个工具还带了一个命令行工具，这是它比 Postman 那套 Newman 流程更轻量的地方。我在 CI 流程里其实没有去调用 GUI，而是直接用命令行跑集合里全部请求。官方文档里给了一种无头运行的方式，命令大致长这样：
bru run 用户中心联调 --env dev这条命令会自动按顺序执行集合里的所有请求，并输出测试报告。加上 --env 参数切环境非常方便。跑完的退出码是 0 还是非 0，直接和 CI 的成败挂钩。
我在公司内部就直接把它接进了 GitLab CI 里，逻辑很简单：每次有人改接口代码，流水线里先把对应的 .bru 集合跑一遍，如果接口返回结构变了导致断言失败，流水线就会红，倒逼开发者同步更新接口调试文档。这个流程对团队协作的帮助很明显，尤其是前后端并行开发的时候，后端接口一改，前端马上就能通过测试报告发现问题，不用再等人来通知。
5. 常见问题与排查技巧实录
5.1 环境变量不生效，请求还是用的旧地址
这个问题我碰到过两次，第一次排查了半天，后来发现自己新建的环境没有点“激活”按钮。它在环境切换上的交互和 Postman 略有不同：Postman 是选一个环境就全局生效，而它除了选择环境，还要求当前请求没有手动覆盖的变量值。如果请求的 Variables 标签页里存在同名变量，环境变量就会被忽略。
解决办法：先切换到目标环境，然后打开具体请求，确认 Variables 标签页为空，再试。如果已经设置了变量又想去掉，直接在 Variables 标签页里删除对应行即可。它本质上是“请求文件里的变量优先于环境变量”，理解了这个规则就不会再困惑。
5.2 中文乱码和字符编码问题
接口联调最怕响应里返回一堆乱码。它在处理部分老系统接口时，如果响应头没有明确 charset=utf-8，可能因为默认按 UTF-8 解析而出现中文乱码。这个问题在 Postman 里也存在，但 Postman 会根据响应头自动判断一些情况。
我实际遇到的一次是某个 Java 老项目接口返回 JSON 但 Content-Type 是 application/json，没有 charset 字段，而实际编码是 GBK。这个工具按 UTF-8 解析就直接乱码了。解决办法有两个：一是建议服务端加上 charset=utf-8（这个治本）；二是在工具这边，可以考虑先用命令行或者浏览器验证一下接口原始字节，确认编码格式。不过说实话，现在这种纯 GBK 的老接口越来越少了，真遇到也就是特殊处理一下，不会常驻影响日常开发。
5.3 导入 Postman 的集合之后脚本失效了
从 Postman 迁移的时候，最麻烦的不是请求本身，而是脚本。Postman 里的脚本使用了 pm.* 这一套全局 API，而这个工具则使用 bru.* 的 API，虽然很多命名很相似，但直接拷贝是运行不了的。比如 Postman 里设置环境变量用的是 pm.environment.set("key", value)，到这边就得改成 bru.setVar("key", value)。
我第一次导入的时候，集合里的 20 多个请求全部导入成功，但几乎所有带脚本的请求都不能正常运行。当时我没逐个检查，直接跑了集合，结果是十几个请求全部报错，以为是工具稳定性问题。后来点开一个请求才注意到脚本里还写着 pm.sendRequest 这种老 API，这才意识到是需要翻译脚本的。
如果你有大量 Postman 脚本需要迁移，我给你一个技巧：不要试图逐个请求去改，先总结出你自己最常用的几个模式。像我自己的项目里，无非就是“响应里取字段存变量”“根据环境变量构造 sign”“断言状态码”。把这三种模式在替代工具里各写一遍作为模板，后续就是复制粘贴替换字段名的机械工作，一两个小时就能处理完几百个请求。
5.4 大响应体的性能表现
还有一个场景是调试大接口，有个搜索接口返回的是上万条记录，JSON 体大概 8MB。在 Postman 里打开这种响应，滚动查看的时候会有明显卡顿。而这个工具因为采用的是轻量渲染，反而没有这个问题，滚动流畅度好不少。不过它也没有 Postman 那种格式化的可视化 JSON 树，大部分时候只能看原始 JSON 文本，需要自己心里有数或者借助 IDE。对于日常排错来说，纯文本 JSON 已经够用了。
6. 工具选型之争：它和 Postman 到底谁更合适
6.1 不同场景下的选择建议
不做选择题是不可能的。如果你只是一个人开发，偶尔测个接口，那选谁完全看心情。但如果你要考虑团队协作、CI 集成、离线环境、多环境管理这些因素，那就有得聊了。
适合迁移到轻量替代工具的场景：
- 项目代码本身就是 Git 管理，希望接口调试文档和代码同步进仓库的
- 对隐私敏感，不希望所有请求记录都上传到云端的
- 电脑配置一般，Postman 一到手就卡得动不了的
- 离线内网环境开发，没法用 Postman 在线登录功能的
- 需要把接口冒烟测试跑进 CI 流水线的，命令行工具很有价值
反过来，如果你重度依赖 Postman 的云端 team workspace 协作、或者需要 Postman 的在线文档分享功能、又或者你的团队已经围绕 Postman 生态建立了完整的测试体系，那暂时留到 Postman 也合理。毕竟迁移成本不在工具本身，而在人。
6.2 我在真实项目里的分工节奏
我现在的工作方式是：Postman 留在老项目里，不动。新项目一律用轻量替代工具，把 .bru 文件直接提交到 Git 仓库。日常本地调试、环境切换、快速验证都在新工具里完成；只有需要临时看一下之前 Postman 里面的老集合定义时，才打开一次 Postman。这让我电脑上的内存从常驻 1GB+ 降到了 300MB 左右，风扇都不怎么转了。
如果你也打算像我这样混着用，记住一个原则：同一个接口别在两个工具里同时维护，不然两边定义漂移了反而更糟。新项目用新流程，老项目有历史包袱就先维持原样，等重构的时候再顺势迁移。
7. 总结与下一步扩展
用这个 10MB 出头的轻量替代方案替换掉 Postman，是不是适合每个人，我不敢打包票。但对我自己来说，最大的收获不是省了那不到 1GB 的内存，而是它把我从 Postman 账号、云同步、索引缓存这些“接口调试之外的事情”里解放了出来。启动快、数据本地化、文件即接口、命令行可跑 CI，这些点真正契合了我日常的开发节奏。
如果你决定试试，我建议别急着整体迁移，先把一两个常用的请求导进来，发几个接口，建一下环境变量，感受下交互差异。然后选一个不重要的项目，把集合目录提交到 Git 里，体验一下接口文档跟着代码走的感觉。觉得顺手了，再扩大迁移范围也不迟。
就我个人实际使用体验来说，这个工具的价值不在于它比 Postman 少了多少功能，而在于它把和真正的测试调试无关的杂音全部剔除了，留下的东西都足够日常使用。最后再分享一个小技巧：把新建请求的快捷键和 IDE 里的 Git 提交键配合起来，我现在的习惯是改完接口、写完断言、提交代码一条龙，根本不用在两个窗口之间来回切，测试代码和调试记录也不会出现“忘了更新 Postman”的尴尬情况。
