记得有一次改登录接口前后花了一个多小时实际改代码只花了二十分钟剩下时间全耗在工具切换上切到 Postman、找到对应的 Collection、点开登录请求、确认环境变量、复制粘贴新 token、再切回 IDEA 继续改。这种来回折腾的次数多了我就把目光盯上了 IDEA 自带的那套 HTTP Client——也就是大家口口相传的 IDEA REST Client。研究完得出的结论和这个标题说的一样只要你的主力开发环境是 IDEAPostman 在大部分日常调试场景里真的可以挪出常用席位了。这篇文章不打算把官方文档翻译一遍也不打算逐个 Menu 截图讲我只想从一个真实使用者的角度把“为什么它能替代 Postman、怎么上手、边界在哪、有哪些坑”讲清楚。如果你是一个每天写接口、调接口、被环境切换折腾到烦的开发者这篇应该能帮你省下不少时间。1. 为什么我最终还是把 Postman 放到了“备用工具”栏1.1 真正磨人的不是接口测试是工具切换先说一个我观察了很久的现象大部分人调试接口的流程其实是这样——在 IDEA 里写好 Controller启动 Spring Boot然后切到 Postman找到上次保存的请求手动改一下 IP 端口再改一下 token点发送看响应不对回 IDEA 改代码再切回 Postman 重发。这个循环里真正干活的时间不多大部分时间都花在“找回现场”上。Postman 本身并不难用难用的是它和我们的开发环境是割裂的。代码在 IDEA请求在 Postman变量在两边的配置里token 靠手动复制。每次换环境、换分支、换同事的机器这套“现场”都要重新搭一遍。Postman 其实也有环境变量和 Collection 导出的能力但问题不是它做不到而是它多了一套软件、多了一份数据、多了一次维护工序。请求描述没有和代码待在一起而是躺在另一个工具的收藏夹里这本身就是一种隐性成本。1.2 官方叫 HTTP Client大家叫它 REST Client它在 IDE 里到底是什么身份IDEA 这套内置请求工具官方现在的名字叫 HTTP Client很多老开发者还习惯叫它 REST Client。它不是一个需要单独安装的插件而是 IntelliJ IDEA 自带的一级功能。它的核心单位不是某个面板或弹窗而是一个后缀为.http的纯文本文件。换句话说你在 IDEA 里调试接口本质上是在写一个文本文件。这个文件里有请求行、请求头、请求体有注释有环境变量引用甚至还能写脚本。因为是纯文本所以它能被 Git 管理、能被 Code Review、能被 diff三个同事 clone 同一个仓库就各自拥有同一套接口现场。这一点和 Postman 有本质区别。Postman 的 Collection 也可以导出成 JSON但导出之后基本就是给人看的不能直接在 IDE 里执行。而.http文件既是接口文档又是可执行的调试脚本还是环境配置的载体三个身份合一。1.3 先判断自己适不适合这套玩法别急着卸载 Postman。我先说清楚这套方案的适用人群主力 IDE 是 IntelliJ IDEA日常写的是 Spring Boot、Java、Go、Python 这类服务端项目受够了“写代码一个工具、测接口另一个工具”的两边跑状态项目经常要切换 dev / test / prod 环境或者经常要换机、换人接手希望接口请求能被 Git 管理让新人 clone 代码后直接看到整套请求愿意花一个下午做一次迁移换取之后每天很多次接口调试的便利。反过来如果你的工作重心是完全脱离 IDE 的接口测试、需要经常做团队级协作和文档分享、或者你根本不写代码那 Postman 可能仍是更舒服的选择。工具没有高下重点是匹配工作流。2. 第一课.http 文件就是你的接口工作台2.1 三行代码发第一次请求从创建文件到看响应上手方式比大多数人想象的简单。在项目里任意位置新建一个文件比如api/test.http输入三行内容### 获取用户信息 GET http://localhost:8080/api/users/1 Accept: application/json第一行###是请求分隔符用来区分一个文件里的多个请求。第二行是请求行声明方法和 URL。第三行开始是请求头。写完之后编辑器里每一行左侧会出现一个绿色的运行箭头点一下请求就会发送。第一次发送时IDEA 会在编辑区下方或右侧弹出工具窗口里面展示响应状态、响应耗时、响应大小、响应头和响应体。如果你写过 Postman对这个窗口应该非常熟悉。区别在于这一切都发生在代码编辑器里不需要切换应用窗口。这里有个小细节.http文件的后缀也可以写成.rest两者本质一样。IDEA 会对这个文件做语法高亮、URL 参数补全、请求头联想写起来跟写代码差不多。第一次跑通请求之后你大概率会有种“原来这么简单”的感觉。2.2 请求语法速查JSON、表单、文件上传一次说清跑通 GET 之后下一个自然需求就是 POST。写法和日常直觉一致### 创建用户 POST http://localhost:8080/api/users Content-Type: application/json { name: Java, age: 8 }注意请求体和请求头之间要空一行这跟我们写 HTTP 报文的结构是一样的。表单提交也类似### 登录 POST http://localhost:8080/api/login Content-Type: application/x-www-form-urlencoded usernameadminpassword123456文件上传稍微特殊一点需要手动声明 multipart boundary再通过符号把本地文件内容读进来### 上传文件 POST http://localhost:8080/api/upload Content-Type: multipart/form-data; boundaryWebAppBoundary --WebAppBoundary Content-Disposition: form-data; namefile; filenametest.txt Content-Type: text/plain ./test.txt --WebAppBoundary--这里的./test.txt是相对当前.http文件所在目录的路径。这个用法我一开始也没注意翻到官方示例才发现后来传文件基本都是这么干的。下面是几个常用方法的快速对照方便查方法示例片段说明GETGET http://localhost:8080/api/users/1查询可带 query 参数POSTPOST http://localhost:8080/api/users创建JSON body 写在空行后PUTPUT http://localhost:8080/api/users/1更新整个资源DELETEDELETE http://localhost:8080/api/users/1删除资源PATCHPATCH http://localhost:8080/api/users/1局部更新2.3 从浏览器或 Postman 把请求搬进来cURL 粘贴大法很多人担心迁移成本觉得要把以前在 Postman 里配好的请求一个个手动重新敲一遍。其实完全不用。IDEA 的 HTTP Client 支持从剪贴板导入 cURL 请求。操作很简单在 Postman 或浏览器开发者工具里把一个请求复制成 cURL 格式然后在 IDEA 的.http文件编辑区右键选择类似“Paste as a request from clipboard”的选项IDEA 会自动解析 cURL生成对应的请求块。这个方法我第一次用的时候有点惊艳。以前调第三方接口时习惯从浏览器 F12 里复制请求现在直接粘到 IDEA 里就能跑请求头、cookie、query 参数都带过来了。从 Postman 迁移也不用一笔一笔地重新记把常用的请求导出成 cURL批量粘到.http文件里再做些变量替换迁移基本就完成了。2.4 响应窗口和请求历史这些细节值得留意HTTP Client 的响应窗口里除了常见的响应体预览之外响应头和状态行也会展示方便排查编码、重定向这类问题。还有一个容易被忽略的地方IDEA 会在项目里的.idea/httpRequests/目录下保存最近的请求日志里面包含完整的请求和响应内容。这个目录对排查问题特别有用比如你忘了刚才某个请求发了什么 body翻日志就能找回来。另外IDEA 支持把请求导出成 cURL右键请求块就能看到。这个功能在很多需要“把请求贴给同事看”的场景里非常实用。即使对方不用 IDEA也能拿着 cURL 在自己环境里跑。3. 环境变量与动态值一套 .http 文件跑通所有环境3.1 http-client.env.json多环境配置的正确姿势本地联调和测试环境联调最烦的就是 URL 和鉴权信息不一样。Postman 里可以用 Environment 管理但每次切换环境要在下拉框里选来选去。IDEA 的方案更直接在项目根目录创建一个http-client.env.json文件。这个文件的内容长这样{ dev: { host: http://localhost:8080, username: admin, password: 123456 }, test: { host: http://test.example.com, username: testadmin, password: test123 } }然后在.http文件里把 URL 中的主机名替换成变量引用### 登录 POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} }运行请求时点击请求行左侧的箭头IDEA 会弹出环境选择框选dev跑本地选test跑测试环境。最重要的是这个切换是请求级别的同一个.http文件里所有请求块共享同一套环境变量换一次环境整份文件都跟着换不用像以前那样逐个请求改 URL。有一点要注意http-client.env.json是共享配置文件默认会提交到 Git。如果里面有生产环境的密码、token 这类敏感信息建议新建一个http-client.private.env.json放私密变量。IDEA 支持这两个文件配合使用公共变量放共享文件私密变量放私有文件。我在项目里一般把 host、username、公开测试账号放共享文件真实密码和 token 放私有文件并且把私有文件写进.gitignore。3.2 动态值uuid、时间戳、随机数一个都不用手改调试接口时经常要造数据比如订单号要求唯一、创建时间要填当前时间、测试一个列表要传随机页码。手写这些太麻烦而且容易踩重复数据的坑。IDEA HTTP Client 自带一组动态值直接写在请求里就行### 创建订单 POST http://{{host}}/api/order Content-Type: application/json { orderId: {{$uuid}}, createdAt: {{$timestamp}}, amount: {{$randomInt}} }{{$uuid}}会生成一个 UUID{{$timestamp}}会生成当前时间戳{{$randomInt}}会生成一个随机整数。实际用下来我比较常用的还有{{$random.email}}生成随机邮箱、{{$random.alphabetic(8)}}生成 8 位随机字母。有了这些造测试数据基本不用手动改。动态值的意义不只是省事。它还让请求具备了“可重复执行”的能力。同一个.http文件今天跑和明天跑、你跑和同事跑都会生成不同的合法数据不会因为撞了主键而失败。3.3 从响应里提取 tokenclient.global.set 实现自动登录态这个功能我觉得是整篇文章里最值得学的。日常调接口最烦的一步就是登录拿 token然后把 token 手动复制到后续请求的 Header 里。如果 token 有效期短还得反复来。IDEA HTTP Client 支持在请求发出后执行一段 JavaScript 脚本去处理响应在这个脚本里可以把响应中的数据存成全局变量供后面的请求使用。看代码### 1. 登录 POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} } {% const json response.body; client.global.set(token, json.data.token); client.log(token saved: json.data.token); %}接下来创建订单的请求直接引用这个 token### 2. 创建订单 POST http://{{host}}/api/order Content-Type: application/json Authorization: Bearer {{token}} { productId: P001, quantity: 2 }只要先运行登录请求token 就会被自动保存再运行创建订单请求Header 里的{{token}}会自动替换成刚保存的值。整个过程不需要离开 IDEA、不需要复制粘贴顺序跑一遍就完成了。我第一次跑通这套链路的时候真的有一种“这才对嘛”的感觉——接口调试本来就该是这样自动化的而不是每次手动复制 token。4. 脚本与自动化这才是 Postman 可以被替换的关键4.1 response handler scripts请求跑完顺便做断言我们调试接口时总会下意识看一眼响应体判断对不对但接口多了之后肉眼检查其实很不可靠。IDEA HTTP Client 支持响应处理脚本可以在请求返回后自动做校验结果会直接显示在响应窗口里。基础用法是这样### 查询订单 GET http://{{host}}/api/order/{{$randomInt}} Accept: application/json {% client.test(查询返回 200, function() { client.assert(response.status 200, 状态码不是 200); }); client.test(订单号存在, function() { client.assert(response.body.data.orderId, 订单号为空); }); %}跑完请求窗口里能看到每个测试用例的通过情况不用自己去数 JSON 字段了。这里能用的 API 主要也就几个client.test定义一个测试用例、client.assert做条件断言、client.log输出日志。跟 Postman 的 Tests 脚本逻辑类似但写起来更贴近 JavaScript 原生习惯。我实际项目里会把一套核心接口的断言都写上。虽然平时主要靠眼睛看但偶尔改接口把字段名改了、状态码变了这些断言会在第一时间提醒我比在对接前端时被发现要体面得多。4.2 接口资产进 Git团队新人不靠拷贝也能接手这是我认为“替代 Postman”最有说服力的一点。以前团队里来了新人要联调一个模块的接口通常得找人要 Postman Collection 链接或者对着接口文档自己建请求。现在只要项目的api/目录下有一套.http文件新人 clone 代码后打开文件选中环境点箭头就全通了。而且接口和代码在一个仓库里有天然的同步关系。你改了 Controller 的路径提交代码时势必会看到对应.http文件里的 URL 也应该改一改这就是把文档和实现绑定在一起的好处。Postman 的 Collection 可以导出、可以同步但它和代码仓库之间的连接是断的靠的是人的自觉。同时Code Review 的时候评审者可以直接看.http文件里的请求示例快速理解接口的输入输出。有些时候接口文档写得不全但.http文件是能跑的比文档准。4.3 别忽视的“隐形能力”与 JUnit、CI 的结合思路HTTP Client 本身不是测试框架不能替代 JUnit 做自动化回归但它的文本化形式为自动化留下了很多空间。一个简单可行的做法在本地把核心链路登录到下单再到查单跑通把请求内容作为手动验收清单每次发版前按顺序执行一遍全绿了再喊测试同事。这不需要搭任何框架只需要一个.http文件。更进一步如果你想把接口测试纳入自动化回归可以基于这些请求编写 JUnit 测试或者用 RestAssured 这类 Java 测试库把.http文件里的请求逻辑表达出来。请求本身是纯文本很容易转换成测试代码。CI 阶段也可以直接用类似方式执行这些请求作为冒烟测试的参考。这块可以根据项目需要再展开至少思路是通的。5. 完整实战从登录到创建订单的一条龙调试5.1 场景设计与环境准备纸上聊再多不如跑一遍完整流程。我以最常见的电商类业务为例把整个调试过程拆开演示。假设项目里有三个接口登录POST /api/login传用户名密码返回data.token创建订单POST /api/order需要Authorization: Bearer token返回data.orderId查询订单GET /api/order/{orderId}返回订单详情本地开发环境跑在localhost:8080测试环境是test.example.com。按照前面的方法先建好http-client.env.json{ dev: { host: http://localhost:8080, username: admin, password: 123456 }, test: { host: http://test.example.com, username: testadmin, password: test123 } }然后建一个api/order-flow.http文件把三个接口按顺序写进去。5.2 一整个 .http 文件登录、下单、查询全写进去### 1. 登录获取 token POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} } {% const json response.body; client.global.set(token, json.data.token); client.log(token saved: json.data.token); %} ### 2. 创建订单 POST http://{{host}}/api/order Content-Type: application/json Authorization: Bearer {{token}} { productId: P-{{$randomInt}}, quantity: 2 } {% client.test(创建订单成功, function() { client.assert(response.status 200, 创建订单失败状态码 response.status); client.global.set(orderId, response.body.data.orderId); client.log(orderId: response.body.data.orderId); }); %} ### 3. 查询订单 GET http://{{host}}/api/order/{{orderId}} Accept: application/json {% client.test(查询订单成功, function() { client.assert(response.status 200, 查询订单失败状态码 response.status); }); client.test(订单状态正确, function() { client.assert(response.body.data.status CREATED, 订单状态不是 CREATED); }); %}跑的时候从上到下依次点运行箭头。第一步登录后client.global.set会把 token 存下来第二步创建订单时Header 里的{{token}}会自动替换第二步响应脚本又把orderId存下来第三步查询订单时URL 里的{{orderId}}也会被替换。整个过程完全不碰 Postman不看浏览器不复制任何 token 或 ID。跑第二遍的时候{{$randomInt}}会让 productId 换一个新值{{$uuid}}这类动态值也会避免数据冲突。5.3 跑完一遍之后的复盘这笔投入到底值不值三请求链路写完我的直观感受是这套组合拳的价值不在于某一个功能有多强而在于所有东西都长在一个地方。请求是文件环境是文件脚本是文件Git 可以记录它们的每一次变化。接口从“a 参数改成 b 参数”到“响应里多了个字段”到“token 失效条件变了”所有演进历史都在 request 文件里能看到。这比 Postman 的收藏夹要可靠得多也更容易让整个团队形成统一习惯。唯一要做的适应是从“点开 Postman 找请求”变成“点开 IDEA 里的 .http 文件跑请求”。这个切换只需要两三天的习惯养成期。习惯之后那种来回切换工具的精神损耗基本就消失了。6. 边界要说清楚什么时候还得把 Postman 请回来6.1 团队可视化协作Postman 的护城河仍然存在说“丢掉 Postman”多少有些标题党的味道。作为一个用了两套工具的人我承认 IDEA HTTP Client 有明确的边界。首先是团队协作层面。Postman 的 Collection 可以分享链接、可以嵌入文档站、有权限管理、有云端同步。前端同事、测试同事、产品同事可以基于同一个链接查看接口列表和文档这些能力是.http文件暂时替代不了的。如果你的团队需要一个“所有不懂 IDEA 的人都能打开看”的接口资产库Postman 依然是更省事的选择。6.2 浏览器抓包与复杂 OAuth2不是不能写是没必要另一个替代不了的点是浏览器会话捕获。Postman 的 Interceptor 能直接抓浏览器的 Cookie 和请求自动带入到测试请求中对排查前端问题很有用。IDEA HTTP Client 没有对等的可视化抓包能力要拿到登录后的 Cookie 得靠手动复制体验就差一些。复杂 OAuth2 授权流程也一样。Postman 有图形化的 OAuth2 配置界面能自动完成 authorization code 模式下的授权码换取、token 刷新、重定向处理。IDEA 这边要做类似事情就得写脚本模拟能实现但投入产出比不高。如果你经常要调 OAuth2 或企业微信这类需要授权码换 token 的接口保留 Postman 更划算。6.3 告别“万能”幻想压测和性能验证不该找它最后要说清楚的是定位。HTTP Client 的目标是“单请求调试”它不是性能测试工具。没有并发模型没有图形化聚合报告没有阶梯加压。想压测接口、验证性能瓶颈千万别指望它。该用 JMeter、Gatling、wrk 这类专业工具还是得用。我的结论是Postman 不是被物理丢弃而是从“必开应用”变成“按需打开的工具”。日常编码期、联调期、自测期IDEA HTTP Client 完全接得住需要做文档分享、复杂授权、团队级接口资产管理时再把 Postman 请出来。两个工具各管一段比只用一个硬扛所有场景要好得多。7. 从 Postman 迁移到 REST Client 的避坑笔记7.1 环境变量、编码、路径先记住这三个高频翻车点迁移过程中我踩过几个坑列出来给你省时间。第一个是环境变量不生效。表现是请求里写了{{host}}但运行时没有被替换。原因通常是运行请求之前没有在弹出框里选中环境或者http-client.env.json文件名拼错了。注意文件名必须严格是http-client.env.json大小写和连字符都不能变。第二个是响应中文乱码。这背后可能是.http文件本身的编码问题也可能是服务端返回的 Content-Type 没有带charsetutf-8。先在 IDEA 设置里确认文件的默认编码是 UTF-8再检查服务端响应头。如果服务端没声明 charset可以在请求块里加Accept-Charset: UTF-8或者让后端的框架统一配置响应编码。第三个是相对路径问题。文件上传用 ./test.txt这种写法时路径是相对于.http文件所在目录的不是相对于项目根目录。把文件放在与.http同级的目录下或者写清相对路径能少踩坑。7.2 不同 IDEA 版本的界面差异抓住底层逻辑不迷路IDEA 版本迭代很快HTTP Client 的界面一直在变。比如新版本支持了请求集合的概念环境变量下拉框的位置也有所调整。如果你按某篇老教程找不到按钮别慌记住底层逻辑就行所有请求都是.http文件里的文本块只要会写文本任何版本的 IDEA 都能跑。头部的脚本区域、###分隔符、{{}}变量引用这些语法是基本稳定的。另外.http文件的位置不用太纠结。按模块建目录比如api/auth.http、api/order.http、api/user.http内容多了自然成体系。我一般还会在api/README.md里简单说明每个文件的用途方便后来者快速上手。7.3 给准备切换的人三个习惯建议最后分享几个我实际用下来很有用的习惯。第一核心链路请求一定要写断言。不要觉得麻烦写一个client.test只需要十几秒但接口回归检查的时间会从“肉眼看半天”变成“一秒看结果”。第二敏感信息放http-client.private.env.json公共信息放http-client.env.json私有文件加入.gitignore。这样既能让团队共享主机地址和测试账号又不会把真实 token 和密码提交到仓库里。第三团队内推广时不用强制所有人立刻放弃 Postman。可以先在一个模块里试点把常用接口整理成.http文件大家跑通几次后自然会感受到“上下文不切换”的爽快感然后慢慢迁移其他模块。我在实际项目中用了这套方案一段时间后最大的体会不是“Postman 不好”而是“接口调试这件事本质上也是一种写代码的工作”。让它回归代码文件让 Git 管理历史让同事 clone 下来就能看到整套接口定义这种收益比想象中要大。如果你也是 IDEA 的重度用户建议先腾一个下午把常用的五六个接口写成.http文件加上环境变量和 token 自动提取跑通两三条链路。这一下午的投入之后每天都会给你回报。剩下的 Postman就留给它真正擅长的事。 
长河君 · 2026/10/2 21:50:33 · 阅读 1.2k IDEA HTTP Client实战：.http文件替代Postman的调试指南
记得有一次改登录接口前后花了一个多小时实际改代码只花了二十分钟剩下时间全耗在工具切换上切到 Postman、找到对应的 Collection、点开登录请求、确认环境变量、复制粘贴新 token、再切回 IDEA 继续改。这种来回折腾的次数多了我就把目光盯上了 IDEA 自带的那套 HTTP Client——也就是大家口口相传的 IDEA REST Client。研究完得出的结论和这个标题说的一样只要你的主力开发环境是 IDEAPostman 在大部分日常调试场景里真的可以挪出常用席位了。这篇文章不打算把官方文档翻译一遍也不打算逐个 Menu 截图讲我只想从一个真实使用者的角度把“为什么它能替代 Postman、怎么上手、边界在哪、有哪些坑”讲清楚。如果你是一个每天写接口、调接口、被环境切换折腾到烦的开发者这篇应该能帮你省下不少时间。1. 为什么我最终还是把 Postman 放到了“备用工具”栏1.1 真正磨人的不是接口测试是工具切换先说一个我观察了很久的现象大部分人调试接口的流程其实是这样——在 IDEA 里写好 Controller启动 Spring Boot然后切到 Postman找到上次保存的请求手动改一下 IP 端口再改一下 token点发送看响应不对回 IDEA 改代码再切回 Postman 重发。这个循环里真正干活的时间不多大部分时间都花在“找回现场”上。Postman 本身并不难用难用的是它和我们的开发环境是割裂的。代码在 IDEA请求在 Postman变量在两边的配置里token 靠手动复制。每次换环境、换分支、换同事的机器这套“现场”都要重新搭一遍。Postman 其实也有环境变量和 Collection 导出的能力但问题不是它做不到而是它多了一套软件、多了一份数据、多了一次维护工序。请求描述没有和代码待在一起而是躺在另一个工具的收藏夹里这本身就是一种隐性成本。1.2 官方叫 HTTP Client大家叫它 REST Client它在 IDE 里到底是什么身份IDEA 这套内置请求工具官方现在的名字叫 HTTP Client很多老开发者还习惯叫它 REST Client。它不是一个需要单独安装的插件而是 IntelliJ IDEA 自带的一级功能。它的核心单位不是某个面板或弹窗而是一个后缀为.http的纯文本文件。换句话说你在 IDEA 里调试接口本质上是在写一个文本文件。这个文件里有请求行、请求头、请求体有注释有环境变量引用甚至还能写脚本。因为是纯文本所以它能被 Git 管理、能被 Code Review、能被 diff三个同事 clone 同一个仓库就各自拥有同一套接口现场。这一点和 Postman 有本质区别。Postman 的 Collection 也可以导出成 JSON但导出之后基本就是给人看的不能直接在 IDE 里执行。而.http文件既是接口文档又是可执行的调试脚本还是环境配置的载体三个身份合一。1.3 先判断自己适不适合这套玩法别急着卸载 Postman。我先说清楚这套方案的适用人群主力 IDE 是 IntelliJ IDEA日常写的是 Spring Boot、Java、Go、Python 这类服务端项目受够了“写代码一个工具、测接口另一个工具”的两边跑状态项目经常要切换 dev / test / prod 环境或者经常要换机、换人接手希望接口请求能被 Git 管理让新人 clone 代码后直接看到整套请求愿意花一个下午做一次迁移换取之后每天很多次接口调试的便利。反过来如果你的工作重心是完全脱离 IDE 的接口测试、需要经常做团队级协作和文档分享、或者你根本不写代码那 Postman 可能仍是更舒服的选择。工具没有高下重点是匹配工作流。2. 第一课.http 文件就是你的接口工作台2.1 三行代码发第一次请求从创建文件到看响应上手方式比大多数人想象的简单。在项目里任意位置新建一个文件比如api/test.http输入三行内容### 获取用户信息 GET http://localhost:8080/api/users/1 Accept: application/json第一行###是请求分隔符用来区分一个文件里的多个请求。第二行是请求行声明方法和 URL。第三行开始是请求头。写完之后编辑器里每一行左侧会出现一个绿色的运行箭头点一下请求就会发送。第一次发送时IDEA 会在编辑区下方或右侧弹出工具窗口里面展示响应状态、响应耗时、响应大小、响应头和响应体。如果你写过 Postman对这个窗口应该非常熟悉。区别在于这一切都发生在代码编辑器里不需要切换应用窗口。这里有个小细节.http文件的后缀也可以写成.rest两者本质一样。IDEA 会对这个文件做语法高亮、URL 参数补全、请求头联想写起来跟写代码差不多。第一次跑通请求之后你大概率会有种“原来这么简单”的感觉。2.2 请求语法速查JSON、表单、文件上传一次说清跑通 GET 之后下一个自然需求就是 POST。写法和日常直觉一致### 创建用户 POST http://localhost:8080/api/users Content-Type: application/json { name: Java, age: 8 }注意请求体和请求头之间要空一行这跟我们写 HTTP 报文的结构是一样的。表单提交也类似### 登录 POST http://localhost:8080/api/login Content-Type: application/x-www-form-urlencoded usernameadminpassword123456文件上传稍微特殊一点需要手动声明 multipart boundary再通过符号把本地文件内容读进来### 上传文件 POST http://localhost:8080/api/upload Content-Type: multipart/form-data; boundaryWebAppBoundary --WebAppBoundary Content-Disposition: form-data; namefile; filenametest.txt Content-Type: text/plain ./test.txt --WebAppBoundary--这里的./test.txt是相对当前.http文件所在目录的路径。这个用法我一开始也没注意翻到官方示例才发现后来传文件基本都是这么干的。下面是几个常用方法的快速对照方便查方法示例片段说明GETGET http://localhost:8080/api/users/1查询可带 query 参数POSTPOST http://localhost:8080/api/users创建JSON body 写在空行后PUTPUT http://localhost:8080/api/users/1更新整个资源DELETEDELETE http://localhost:8080/api/users/1删除资源PATCHPATCH http://localhost:8080/api/users/1局部更新2.3 从浏览器或 Postman 把请求搬进来cURL 粘贴大法很多人担心迁移成本觉得要把以前在 Postman 里配好的请求一个个手动重新敲一遍。其实完全不用。IDEA 的 HTTP Client 支持从剪贴板导入 cURL 请求。操作很简单在 Postman 或浏览器开发者工具里把一个请求复制成 cURL 格式然后在 IDEA 的.http文件编辑区右键选择类似“Paste as a request from clipboard”的选项IDEA 会自动解析 cURL生成对应的请求块。这个方法我第一次用的时候有点惊艳。以前调第三方接口时习惯从浏览器 F12 里复制请求现在直接粘到 IDEA 里就能跑请求头、cookie、query 参数都带过来了。从 Postman 迁移也不用一笔一笔地重新记把常用的请求导出成 cURL批量粘到.http文件里再做些变量替换迁移基本就完成了。2.4 响应窗口和请求历史这些细节值得留意HTTP Client 的响应窗口里除了常见的响应体预览之外响应头和状态行也会展示方便排查编码、重定向这类问题。还有一个容易被忽略的地方IDEA 会在项目里的.idea/httpRequests/目录下保存最近的请求日志里面包含完整的请求和响应内容。这个目录对排查问题特别有用比如你忘了刚才某个请求发了什么 body翻日志就能找回来。另外IDEA 支持把请求导出成 cURL右键请求块就能看到。这个功能在很多需要“把请求贴给同事看”的场景里非常实用。即使对方不用 IDEA也能拿着 cURL 在自己环境里跑。3. 环境变量与动态值一套 .http 文件跑通所有环境3.1 http-client.env.json多环境配置的正确姿势本地联调和测试环境联调最烦的就是 URL 和鉴权信息不一样。Postman 里可以用 Environment 管理但每次切换环境要在下拉框里选来选去。IDEA 的方案更直接在项目根目录创建一个http-client.env.json文件。这个文件的内容长这样{ dev: { host: http://localhost:8080, username: admin, password: 123456 }, test: { host: http://test.example.com, username: testadmin, password: test123 } }然后在.http文件里把 URL 中的主机名替换成变量引用### 登录 POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} }运行请求时点击请求行左侧的箭头IDEA 会弹出环境选择框选dev跑本地选test跑测试环境。最重要的是这个切换是请求级别的同一个.http文件里所有请求块共享同一套环境变量换一次环境整份文件都跟着换不用像以前那样逐个请求改 URL。有一点要注意http-client.env.json是共享配置文件默认会提交到 Git。如果里面有生产环境的密码、token 这类敏感信息建议新建一个http-client.private.env.json放私密变量。IDEA 支持这两个文件配合使用公共变量放共享文件私密变量放私有文件。我在项目里一般把 host、username、公开测试账号放共享文件真实密码和 token 放私有文件并且把私有文件写进.gitignore。3.2 动态值uuid、时间戳、随机数一个都不用手改调试接口时经常要造数据比如订单号要求唯一、创建时间要填当前时间、测试一个列表要传随机页码。手写这些太麻烦而且容易踩重复数据的坑。IDEA HTTP Client 自带一组动态值直接写在请求里就行### 创建订单 POST http://{{host}}/api/order Content-Type: application/json { orderId: {{$uuid}}, createdAt: {{$timestamp}}, amount: {{$randomInt}} }{{$uuid}}会生成一个 UUID{{$timestamp}}会生成当前时间戳{{$randomInt}}会生成一个随机整数。实际用下来我比较常用的还有{{$random.email}}生成随机邮箱、{{$random.alphabetic(8)}}生成 8 位随机字母。有了这些造测试数据基本不用手动改。动态值的意义不只是省事。它还让请求具备了“可重复执行”的能力。同一个.http文件今天跑和明天跑、你跑和同事跑都会生成不同的合法数据不会因为撞了主键而失败。3.3 从响应里提取 tokenclient.global.set 实现自动登录态这个功能我觉得是整篇文章里最值得学的。日常调接口最烦的一步就是登录拿 token然后把 token 手动复制到后续请求的 Header 里。如果 token 有效期短还得反复来。IDEA HTTP Client 支持在请求发出后执行一段 JavaScript 脚本去处理响应在这个脚本里可以把响应中的数据存成全局变量供后面的请求使用。看代码### 1. 登录 POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} } {% const json response.body; client.global.set(token, json.data.token); client.log(token saved: json.data.token); %}接下来创建订单的请求直接引用这个 token### 2. 创建订单 POST http://{{host}}/api/order Content-Type: application/json Authorization: Bearer {{token}} { productId: P001, quantity: 2 }只要先运行登录请求token 就会被自动保存再运行创建订单请求Header 里的{{token}}会自动替换成刚保存的值。整个过程不需要离开 IDEA、不需要复制粘贴顺序跑一遍就完成了。我第一次跑通这套链路的时候真的有一种“这才对嘛”的感觉——接口调试本来就该是这样自动化的而不是每次手动复制 token。4. 脚本与自动化这才是 Postman 可以被替换的关键4.1 response handler scripts请求跑完顺便做断言我们调试接口时总会下意识看一眼响应体判断对不对但接口多了之后肉眼检查其实很不可靠。IDEA HTTP Client 支持响应处理脚本可以在请求返回后自动做校验结果会直接显示在响应窗口里。基础用法是这样### 查询订单 GET http://{{host}}/api/order/{{$randomInt}} Accept: application/json {% client.test(查询返回 200, function() { client.assert(response.status 200, 状态码不是 200); }); client.test(订单号存在, function() { client.assert(response.body.data.orderId, 订单号为空); }); %}跑完请求窗口里能看到每个测试用例的通过情况不用自己去数 JSON 字段了。这里能用的 API 主要也就几个client.test定义一个测试用例、client.assert做条件断言、client.log输出日志。跟 Postman 的 Tests 脚本逻辑类似但写起来更贴近 JavaScript 原生习惯。我实际项目里会把一套核心接口的断言都写上。虽然平时主要靠眼睛看但偶尔改接口把字段名改了、状态码变了这些断言会在第一时间提醒我比在对接前端时被发现要体面得多。4.2 接口资产进 Git团队新人不靠拷贝也能接手这是我认为“替代 Postman”最有说服力的一点。以前团队里来了新人要联调一个模块的接口通常得找人要 Postman Collection 链接或者对着接口文档自己建请求。现在只要项目的api/目录下有一套.http文件新人 clone 代码后打开文件选中环境点箭头就全通了。而且接口和代码在一个仓库里有天然的同步关系。你改了 Controller 的路径提交代码时势必会看到对应.http文件里的 URL 也应该改一改这就是把文档和实现绑定在一起的好处。Postman 的 Collection 可以导出、可以同步但它和代码仓库之间的连接是断的靠的是人的自觉。同时Code Review 的时候评审者可以直接看.http文件里的请求示例快速理解接口的输入输出。有些时候接口文档写得不全但.http文件是能跑的比文档准。4.3 别忽视的“隐形能力”与 JUnit、CI 的结合思路HTTP Client 本身不是测试框架不能替代 JUnit 做自动化回归但它的文本化形式为自动化留下了很多空间。一个简单可行的做法在本地把核心链路登录到下单再到查单跑通把请求内容作为手动验收清单每次发版前按顺序执行一遍全绿了再喊测试同事。这不需要搭任何框架只需要一个.http文件。更进一步如果你想把接口测试纳入自动化回归可以基于这些请求编写 JUnit 测试或者用 RestAssured 这类 Java 测试库把.http文件里的请求逻辑表达出来。请求本身是纯文本很容易转换成测试代码。CI 阶段也可以直接用类似方式执行这些请求作为冒烟测试的参考。这块可以根据项目需要再展开至少思路是通的。5. 完整实战从登录到创建订单的一条龙调试5.1 场景设计与环境准备纸上聊再多不如跑一遍完整流程。我以最常见的电商类业务为例把整个调试过程拆开演示。假设项目里有三个接口登录POST /api/login传用户名密码返回data.token创建订单POST /api/order需要Authorization: Bearer token返回data.orderId查询订单GET /api/order/{orderId}返回订单详情本地开发环境跑在localhost:8080测试环境是test.example.com。按照前面的方法先建好http-client.env.json{ dev: { host: http://localhost:8080, username: admin, password: 123456 }, test: { host: http://test.example.com, username: testadmin, password: test123 } }然后建一个api/order-flow.http文件把三个接口按顺序写进去。5.2 一整个 .http 文件登录、下单、查询全写进去### 1. 登录获取 token POST http://{{host}}/api/login Content-Type: application/json { username: {{username}}, password: {{password}} } {% const json response.body; client.global.set(token, json.data.token); client.log(token saved: json.data.token); %} ### 2. 创建订单 POST http://{{host}}/api/order Content-Type: application/json Authorization: Bearer {{token}} { productId: P-{{$randomInt}}, quantity: 2 } {% client.test(创建订单成功, function() { client.assert(response.status 200, 创建订单失败状态码 response.status); client.global.set(orderId, response.body.data.orderId); client.log(orderId: response.body.data.orderId); }); %} ### 3. 查询订单 GET http://{{host}}/api/order/{{orderId}} Accept: application/json {% client.test(查询订单成功, function() { client.assert(response.status 200, 查询订单失败状态码 response.status); }); client.test(订单状态正确, function() { client.assert(response.body.data.status CREATED, 订单状态不是 CREATED); }); %}跑的时候从上到下依次点运行箭头。第一步登录后client.global.set会把 token 存下来第二步创建订单时Header 里的{{token}}会自动替换第二步响应脚本又把orderId存下来第三步查询订单时URL 里的{{orderId}}也会被替换。整个过程完全不碰 Postman不看浏览器不复制任何 token 或 ID。跑第二遍的时候{{$randomInt}}会让 productId 换一个新值{{$uuid}}这类动态值也会避免数据冲突。5.3 跑完一遍之后的复盘这笔投入到底值不值三请求链路写完我的直观感受是这套组合拳的价值不在于某一个功能有多强而在于所有东西都长在一个地方。请求是文件环境是文件脚本是文件Git 可以记录它们的每一次变化。接口从“a 参数改成 b 参数”到“响应里多了个字段”到“token 失效条件变了”所有演进历史都在 request 文件里能看到。这比 Postman 的收藏夹要可靠得多也更容易让整个团队形成统一习惯。唯一要做的适应是从“点开 Postman 找请求”变成“点开 IDEA 里的 .http 文件跑请求”。这个切换只需要两三天的习惯养成期。习惯之后那种来回切换工具的精神损耗基本就消失了。6. 边界要说清楚什么时候还得把 Postman 请回来6.1 团队可视化协作Postman 的护城河仍然存在说“丢掉 Postman”多少有些标题党的味道。作为一个用了两套工具的人我承认 IDEA HTTP Client 有明确的边界。首先是团队协作层面。Postman 的 Collection 可以分享链接、可以嵌入文档站、有权限管理、有云端同步。前端同事、测试同事、产品同事可以基于同一个链接查看接口列表和文档这些能力是.http文件暂时替代不了的。如果你的团队需要一个“所有不懂 IDEA 的人都能打开看”的接口资产库Postman 依然是更省事的选择。6.2 浏览器抓包与复杂 OAuth2不是不能写是没必要另一个替代不了的点是浏览器会话捕获。Postman 的 Interceptor 能直接抓浏览器的 Cookie 和请求自动带入到测试请求中对排查前端问题很有用。IDEA HTTP Client 没有对等的可视化抓包能力要拿到登录后的 Cookie 得靠手动复制体验就差一些。复杂 OAuth2 授权流程也一样。Postman 有图形化的 OAuth2 配置界面能自动完成 authorization code 模式下的授权码换取、token 刷新、重定向处理。IDEA 这边要做类似事情就得写脚本模拟能实现但投入产出比不高。如果你经常要调 OAuth2 或企业微信这类需要授权码换 token 的接口保留 Postman 更划算。6.3 告别“万能”幻想压测和性能验证不该找它最后要说清楚的是定位。HTTP Client 的目标是“单请求调试”它不是性能测试工具。没有并发模型没有图形化聚合报告没有阶梯加压。想压测接口、验证性能瓶颈千万别指望它。该用 JMeter、Gatling、wrk 这类专业工具还是得用。我的结论是Postman 不是被物理丢弃而是从“必开应用”变成“按需打开的工具”。日常编码期、联调期、自测期IDEA HTTP Client 完全接得住需要做文档分享、复杂授权、团队级接口资产管理时再把 Postman 请出来。两个工具各管一段比只用一个硬扛所有场景要好得多。7. 从 Postman 迁移到 REST Client 的避坑笔记7.1 环境变量、编码、路径先记住这三个高频翻车点迁移过程中我踩过几个坑列出来给你省时间。第一个是环境变量不生效。表现是请求里写了{{host}}但运行时没有被替换。原因通常是运行请求之前没有在弹出框里选中环境或者http-client.env.json文件名拼错了。注意文件名必须严格是http-client.env.json大小写和连字符都不能变。第二个是响应中文乱码。这背后可能是.http文件本身的编码问题也可能是服务端返回的 Content-Type 没有带charsetutf-8。先在 IDEA 设置里确认文件的默认编码是 UTF-8再检查服务端响应头。如果服务端没声明 charset可以在请求块里加Accept-Charset: UTF-8或者让后端的框架统一配置响应编码。第三个是相对路径问题。文件上传用 ./test.txt这种写法时路径是相对于.http文件所在目录的不是相对于项目根目录。把文件放在与.http同级的目录下或者写清相对路径能少踩坑。7.2 不同 IDEA 版本的界面差异抓住底层逻辑不迷路IDEA 版本迭代很快HTTP Client 的界面一直在变。比如新版本支持了请求集合的概念环境变量下拉框的位置也有所调整。如果你按某篇老教程找不到按钮别慌记住底层逻辑就行所有请求都是.http文件里的文本块只要会写文本任何版本的 IDEA 都能跑。头部的脚本区域、###分隔符、{{}}变量引用这些语法是基本稳定的。另外.http文件的位置不用太纠结。按模块建目录比如api/auth.http、api/order.http、api/user.http内容多了自然成体系。我一般还会在api/README.md里简单说明每个文件的用途方便后来者快速上手。7.3 给准备切换的人三个习惯建议最后分享几个我实际用下来很有用的习惯。第一核心链路请求一定要写断言。不要觉得麻烦写一个client.test只需要十几秒但接口回归检查的时间会从“肉眼看半天”变成“一秒看结果”。第二敏感信息放http-client.private.env.json公共信息放http-client.env.json私有文件加入.gitignore。这样既能让团队共享主机地址和测试账号又不会把真实 token 和密码提交到仓库里。第三团队内推广时不用强制所有人立刻放弃 Postman。可以先在一个模块里试点把常用接口整理成.http文件大家跑通几次后自然会感受到“上下文不切换”的爽快感然后慢慢迁移其他模块。我在实际项目中用了这套方案一段时间后最大的体会不是“Postman 不好”而是“接口调试这件事本质上也是一种写代码的工作”。让它回归代码文件让 Git 管理历史让同事 clone 下来就能看到整套接口定义这种收益比想象中要大。如果你也是 IDEA 的重度用户建议先腾一个下午把常用的五六个接口写成.http文件加上环境变量和 token 自动提取跑通两三条链路。这一下午的投入之后每天都会给你回报。剩下的 Postman就留给它真正擅长的事。