开发者工具 · HTTP / 网络速查

API 测试工具

Postman 替代/多 Method/历史

✓本地处理 · 不上传 ✓免费 · 无需登录 ✓无次数限制累计 59 次使用

⚠️ 浏览器 CORS 限制：跨域 API 需服务端允许跨域（返回 Access-Control-Allow-Origin 头）才能读取响应，否则被浏览器拦截 —— 这是浏览器安全机制，非工具缺陷。同源 API 或支持 CORS 的 API 可正常测试。

Postman 替代 · 多 Method · 历史 · 全本地 fetch

查询参数key-value 自动 URL 编码后拼到 URL（?k=v&k2=v2）

尚未发送请求 —— 配置后点「发送」

请求历史history · 本地保存

第一节

关于本工具

About

调试接口时，最烦的不是报错，是换一个请求方法就要重开一个工具。这个工具把 GET、POST、PUT、DELETE 等常用 Method 集中在同一个界面，输入 URL 和参数就能发请求，响应体、状态码、请求耗时一次返回。历史记录自动保存，方便回溯对比。所有请求在浏览器内完成，不会将 URL 或参数上传到任何服务器。

使用场景

壹

联调接口报错排查

后端说「接口好了」，前端调了一天全是 400。两边对着文档吵，谁都不认。用本工具直接输入同一个 URL，逐个切换 GET、POST、PUT、DELETE，看返回体里的具体错误码和 message。发现是后端把 Content-Type 写死了 text/plain，前端传的却是 application/json。工具把 Method 和 Header 拆得清清楚楚，一测就定位到责任方，不用再拉群对质。

贰

第三方回调地址配置

接入微信支付时，需要在商户平台填一个 notify_url。填错了只能等超时才能重试，每次等 30 秒。用本工具先发一个 POST 到自己的测试服务器，看能否收到回调参数；再换 GET 测一下跳转是否正常。把 Method 和参数都调通后，才把地址写到微信后台，一次过，不用反复等超时。

叁

接口文档字段校验

开发写完接口文档，QA 要验证每个字段的边界：必填、可选、长度、枚举值。一条接口十几个字段，用 Postman 要一个个点开编辑。本工具支持在历史记录里直接复用上次的请求体，改一个字段值就发一次，快速跑完所有用例。发现文档里写了「性别传 0/1」，实际传 2 也返回成功——工具返回的 body 里字段没变，说明后端没做校验，直接提 bug。

肆

线上环境接口快照

凌晨线上出故障，怀疑是上游接口改了返回结构。生产环境不能随便调，用本工具对关键接口发一次 GET，把返回的 JSON 完整复制下来，和上周的截图对比。发现某个字段从 string 变成了 array，导致下游解析报错。工具不存任何数据到服务器，请求记录只留在本地历史里，适合对敏感接口做临时快照取证。

伍

跨域调试本地服务

前端在 localhost:3000 跑开发环境，后端接口在 localhost:8080，浏览器直接发请求被跨域拦截。用本工具代替浏览器发送请求，不经过 CORS 限制，直接看到接口的真实返回。先测通 /api/login 拿到 token，再带 token 测 /api/user/info，确认后端逻辑无误后，再回头排查前端代理配置。工具把请求头和返回头都展示出来，方便对比哪一步丢了凭证。

第二节

使用指南

Getting Started

使用步骤

1在「请求 URL」栏粘贴接口地址，从下拉列表选择 Method（GET/POST/PUT/DELETE 等），URL 栏右侧自动显示选中 Method 的标签色
2按需在「Headers」「Params」「Body」标签页填入键值对；Body 支持 raw/JSON/form-data 切换，切换时编辑器语法高亮同步更新
3点击「发送」按钮，右侧响应区立即展示状态码、响应头与响应体；若请求失败，错误信息直接显示在状态码下方
4展开「历史」侧栏，按时间倒序列出最近 50 条请求记录；点击任一条自动回填 URL、Method 与参数，无需重新输入

输入输出示例

输入	输出	说明
GET /users/1	Status: 200 OK Body: {"id":1,"name":"Alice","email":"alice@example.com"}	常规：标准 RESTful GET 请求，验证工具对基本 JSON 响应的解析与状态码显示
POST /users Headers: Content-Type: application/json Body: {"name":"Bob","email":"bob@test.com"}	Status: 201 Created Body: {"id":2,"name":"Bob","email":"bob@test.com"}	常规：POST 创建资源，验证工具支持自定义请求头与 JSON 请求体
DELETE /users/999	Status: 404 Not Found Body: {"error":"User not found"}	边界：请求不存在的资源，验证工具正确显示 404 状态码与错误信息
PUT /users/1 Headers: Content-Type: application/json Body: {"name":"Alice Updated"}	Status: 200 OK Body: {"id":1,"name":"Alice Updated","email":"alice@example.com"}	常规：PUT 更新资源，验证工具支持完整请求流程与响应体回显
GET /users?page=-1	Status: 400 Bad Request Body: {"error":"Invalid page number"}	边界：参数值为负数，验证工具对无效参数的错误处理
POST /users Headers: Content-Type: text/plain Body: not-json	Status: 415 Unsupported Media Type Body: {"error":"Content-Type must be application/json"}	易错：请求头 Content-Type 与请求体格式不匹配，验证工具对 MIME 类型校验的反馈
GET /users?limit=abc	Status: 400 Bad Request Body: {"error":"Invalid query parameter: limit must be a number"}	易错：查询参数类型错误（字符串而非数字），验证工具对参数校验的严格性

常见错误对照

1.POST 请求忘记设置 Content-Type

✗ 错误直接粘贴 JSON 到 Body 后发送，服务端返回 400 或解析为空

✓ 修复在 Headers 里添加 Content-Type: application/json

HTTP 协议要求 Content-Type 告知服务端 Body 格式；缺省时服务端可能按 application/x-www-form-urlencoded 解析，导致 JSON 结构丢失。

2.URL 参数与 Body 参数混用

✗ 错误GET 请求把参数写在 Body 里；或 POST 请求把参数全拼在 URL 后

✓ 修复GET 参数放 URL 查询字符串（?key=value），POST 参数放 Body

RFC 7231 规定 GET 请求不应有 Body（多数服务端忽略），POST 的 Body 才是数据载体。混用会导致参数丢失或语义错误。

3.JSON 字符串里漏转义双引号

✗ 错误{"name": "张三"} 在 Body 中直接写，但实际编辑器里没加外层引号导致解析失败

✓ 修复确保整个 Body 是合法 JSON 字符串，如 {"name": "张三"}（编辑器会自动高亮语法错误）

JSON 规范要求 key 和 string value 必须用双引号包裹；编辑器不自动补全时，漏引号会触发 JSON.parse 异常。

4.Bearer Token 前多写了 'Bearer' 以外的前缀

✗ 错误Authorization: Token eyJhbGciOiJIUzI1NiIs...

✓ 修复Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

OAuth 2.0 标准规定 Bearer Token 必须用 Bearer 作为 type 前缀；写 Token 或 JWT 会导致服务端认证失败（返回 401）。

5.PUT 请求漏传完整资源字段

✗ 错误只传 {"name": "新名称"}，但 API 要求全量替换（缺少其他字段）

✓ 修复传完整资源对象，如 {"id": 1, "name": "新名称", "email": "old@example.com"}

HTTP PUT 是幂等的全量替换；按 REST 惯例，缺失字段会被置空或报错。若只想局部更新，应使用 PATCH 方法。

6.忽略 URL 编码导致特殊字符被截断

✗ 错误查询参数直接写 ?q=hello world（包含空格）

✓ 修复?q=hello%20world 或使用工具提供的 URL 编码按钮

URL 中空格、中文、& 等字符必须百分号编码（RFC 3986），否则服务端解析时可能截断参数或返回 400。

7.响应状态码与业务状态码混淆

✗ 错误看到 HTTP 200 就认为请求完全成功，忽略响应体里的 "code": 50001

✓ 修复先看 HTTP 状态码（200 表示通信正常），再检查响应体中的业务 code 字段

HTTP 状态码只代表传输层结果；业务逻辑错误（如参数校验失败）常返回 200 但附带业务错误码，忽略后者会导致误判。

8.Cookie 未携带导致会话相关接口失败

✗ 错误先调用登录接口拿到 Set-Cookie，后续请求没在 Headers 里带上 Cookie

✓ 修复复制登录响应中的 Set-Cookie 值，手动添加到后续请求的 Cookie 头

HTTP 是无状态协议；服务端通过 Cookie 识别会话。工具不会自动保存 Cookie，需手动传递，否则每次请求都是新会话。

第三节

工作原理

How It Works

核心公式

响应时间(ms) = 请求耗时 + 服务器处理耗时 + 网络传输耗时

变量说明

请求耗时从发送到接收首字节的时间(ms)
服务器处理耗时服务器处理请求并生成响应的时间(ms)
网络传输耗时响应数据从服务器传输到客户端的时间(ms)

示例

测试一个 GET 请求到 https://api.example.com/users，请求耗时 120ms，服务器处理耗时 45ms，网络传输耗时 80ms，则总响应时间 = 120 + 45 + 80 = 245ms。

用户输入本地处理输出结果

第五节

常见问题

Q & A

问这个工具能测 POST 请求带 JSON 体吗？＋

答

可以。本工具支持 GET、POST、PUT、DELETE、PATCH 等主流 HTTP Method。发送 POST 请求时，直接在请求体（Body）编辑区粘贴 JSON 字符串即可，不需要额外设置 Content-Type，工具会自动识别为 application/json。如果接口要求其他格式（如 x-www-form-urlencoded），也能手动切换。

问为什么我发送的请求一直返回 CORS 错误？＋

答

本工具完全在浏览器端运行，发送请求时会受浏览器同源策略限制。如果目标 API 没有在响应头中设置 Access-Control-Allow-Origin，请求会被浏览器拦截，无法拿到响应数据。这是浏览器安全机制，不是工具问题。可以用 JSONP（如果接口支持）或改用后端代理工具（如 Postman 桌面版）绕过。

问这个工具和 Postman 有什么区别？＋

答

核心区别是运行环境。Postman 是桌面客户端，可以绕过浏览器 CORS 限制、保存历史请求、管理环境变量。本工具纯浏览器运行，无需安装，打开即用，适合快速调试一个简单的 API 接口或临时验证请求格式。不支持保存请求记录、环境变量或团队协作，定位是轻量级替代。

问请求历史记录能保存多久？＋

答

本工具为纯前端实现，不保存任何请求历史到服务器。刷新页面或关闭标签页后，当前编辑的 URL、Headers、Body 等数据会丢失。如果需要对请求做持久化记录，建议手动复制 URL 或参数到本地文件。工具本身不提供历史管理功能。

问支持带 Header 的请求吗？比如加 Token？＋

答

支持。工具提供独立的 Headers 编辑区，可以按行添加自定义请求头，格式为 Key: Value。常见场景包括加 Authorization: Bearer <token>、设置 Content-Type 或自定义 Accept。添加后发送请求时这些 Header 会原样附带。如果接口需要设置 Cookie，也可以在 Headers 区域手动写入 Cookie 字段。

问为什么返回的 JSON 显示不全或格式乱了？＋

答

可能原因有两个：一是响应体过大，浏览器渲染区有长度限制（不同浏览器不同，通常在 1-2MB 左右），超出部分自动截断；二是响应内容不是严格合法的 JSON（比如包含注释、单引号替代双引号），工具尝试格式化时失败。建议先查看原始响应（Raw 模式），确认内容完整性后再修复 JSON 格式。

问这个工具能测 HTTPS 接口吗？＋

答

可以，只要是浏览器能正常访问的 HTTPS 地址（证书有效、无混合内容错误），工具就能发送请求。如果目标接口使用自签名证书或过期证书，浏览器会直接拦截，工具也无法发出请求。此时需要先在浏览器中手动信任该证书（访问一次确认风险），再回到工具测试。

隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。