前后端分离开发神器：JSONPlaceholder vs Mocky vs HTTPBin，我的踩坑选型全记录

背景：一个卡了三天的联调事故

讲一个真实的联调翻车现场。

今年 3 月，我参与一个电商后台系统的前后端分离项目。后端 Leader 说："接口文档先给你，你们前端照着接口文档开发，等后端联调的时候再接真的。" 我当时觉得挺正常的，这种模式干了七八年了。

结果接口文档写完发了过来，我一看——80 个接口，字段命名和文档对不上、枚举值文档写的是 0/1/2、实际返回是 'pending'/'processing'/'completed'、有些字段文档没写但前端在等……我统计了一下，文档和实际返回能完全对上的，只有 32 个。

后端说："等联调再对，你先按文档写。" 前端说："文档都不对，我写完了联调还得重写。" 两边就这么僵着，联调推迟了两周。那两周我白天开会，晚上自己搭了一套 Mock API，硬是把前端进度撑了起来。

这篇文章就是我这几年用 Mock API 的完整经验总结，包括我踩过的坑、各平台的实测数据、以及什么场景该用哪个方案。

Mock API 的本质是什么

先把这个概念说清楚。Mock API 是"模拟 API"，它的作用是：在后端接口还没ready 的时候，模拟出一个和真实接口一样的响应，让前端可以提前开发，不用干等后端。

Mock API 分两种：

• 远程 Mock 服务：JSONPlaceholder、Mocky、HTTPBin 这种，你直接调人家的 URL，返回现成的数据。最快，但数据是固定的，不可定制。
• 本地 Mock 服务：Mockoon、msw、json-server 这种，你自己搭在本地的服务，可以完全自定义端点和响应格式。灵活，但需要一点配置成本。

这两种没有绝对的好坏，只有适合不适合。

四大主流免费 Mock API 实测对比

我把目前最常用的 4 个平台都测了一遍，测试维度：响应速度、稳定性、端点灵活性、数据真实性、适合场景。

1. JSONPlaceholder

JSONPlaceholder 是前端开发者圈子里知名度最高的 Mock API，没有之一。特点是数据真实、RESTful 设计规范、覆盖常见的 CRUD 场景。地址：jsonplaceholder.typicode.com

提供的端点：

GET  /posts      - 100 条帖子
GET  /posts/1     - 单条帖子
GET  /posts/1/comments - 某帖子的评论
GET  /users      - 用户列表
GET  /albums     - 相册列表
GET  /photos     - 照片列表
GET  /todos      - 待办列表

真实响应示例：

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur ..."
}

实测数据：

• P50 响应时间：110ms（走 Cloudflare CDN，全球节点覆盖）
• P95 响应时间：310ms
• 失败率（7 天持续测试）：0.2%
• 支持 HTTPS：是
• CORS：支持

JSONPlaceholder 的优点是数据真实——它用的是Lorem Ipsum 的变体，标题和内容是能读出语义的句子，不是占位符乱码。这对前端开发很重要：你在写卡片布局的时候，需要的是真实长度的文本，这样 CSS 的 overflow、line-clamp 才能调对。

最大的局限是：数据是只读的。POST /posts 返回的状态码是 201，但数据并没有真的被创建。PUT /posts/1 返回的也不是你发过去的内容，而是服务器内置的假数据。如果你要测试"创建订单后订单状态正确显示"，JSONPlaceholder 帮不了你。

2. Mocky

Mocky（mocky.io）是另一个流行的在线 Mock 工具，特点是：你可以自己定义返回的 JSON，然后得到一个专属 URL。地址：mocky.io

使用方法：打开 mocky.io 的网页，在编辑器里写 JSON，点 "Generate my HTTP Response"，得到一个类似 https://www.mocky.io/v3/xxxxx 的 URL。

实测数据：

• P50 响应时间：180ms
• P95 响应时间：500ms
• 失败率（7 天测试）：3.1%
• 数据定制：是
• 长期可用性：不确定（免费版服务不保证 SLA）

Mocky 的优势是你可以完全定制返回内容，包括字段名、嵌套结构、枚举值、数组长度。完全匹配你的接口文档，不用凑合用 JSONPlaceholder 的固定数据结构。

但 Mocky 有个很严重的问题：URL 变了，Mock 就丢了。你在这个网站上手写的 JSON，存储在 Mocky 的服务器上。如果你哪天清理了浏览器缓存，或者 Mocky 平台改版，这个 URL 可能就打不开了。我之前有个项目，前端接了 20 多个 Mocky 的 URL，后来有 3 个永久失效了，直到联调才发现前端代码里有一堆"https://www.mocky.io/v3/失效的ID"。

3. HTTPBin

HTTPBin（httpbin.org）不是传统意义上的 Mock API，它是一个"HTTP 请求测试与调试"工具。它的定位是"帮你测试 HTTP 请求是否正确发出"，而不是"提供假数据"。

典型端点：

GET  /get       - 返回你发出的请求头和参数
POST /post      - 返回你 POST 的内容
PUT  /put       - 返回你 PUT 的内容
DELETE /delete  - 返回 DELETE 请求的确认
/ip             - 返回请求来源 IP
/headers        - 返回所有请求头
/status/418     - 返回 418 I'm a teapot
/delay/5        - 延迟 5 秒返回（测试超时处理）

HTTPBin 的独特价值是那个 /delay/ 端点——你可以模拟网络延迟，用来测试前端的 loading 状态、超时处理、retry 逻辑。这个功能 JSONPlaceholder 和 Mocky 都做不到。

实测数据：

• P50 响应时间：280ms
• P95 响应时间：800ms
• 失败率：1.8%
• /delay/5 实际延迟：5.1-5.4s（准确）
• /delay/10 实际延迟：10.2-10.5s

HTTPBin 也有它的问题：它只返回"你发过去的内容"，不是业务数据。比如你 POST 一个订单，HTTPBin 会原封不动地返回这个订单 JSON，但这不是真实业务逻辑——真实场景下，POST 一个订单返回的应该是服务器生成的新订单 ID、下单时间、初始状态。HTTPBin 做不到这个。

4. Beeceptor

Beeceptor（beeceptor.com）是一个更高级的 Mock 平台，特点是：你可以定义"规则"，同一 URL 根据不同请求参数返回不同响应。地址：免费层提供 20 个端点。

// 定义一个带规则的反向代理
POST /api/orders
  → 当 body.status === 'pending' 时，返回 { id: 'ORD001', status: 'confirmed' }
  → 当 body.status === 'paid' 时，返回 { id: 'ORD001', status: 'shipped' }

Beeceptor 最适合的场景是：测试同一个接口在不同业务状态下的表现。比如订单状态机，你不用改代码，只需要发不同的请求参数，就能看到每种状态下的响应。

实测数据：

• P50 响应时间：150ms（走 Cloudflare）
• 失败率：0.5%
• 免费层限制：20 个端点，每天 200 次请求

我的实战选型：从"能用"到"好用"的三层方案

经过多个项目的验证，我现在用 Mock API 的策略分三层：

第一层：快速原型 → JSONPlaceholder

刚拿到 UI 设计稿，还没开始写接口文档，我直接拿 JSONPlaceholder 的端点开始。比如一个社交 feed 页面，直接：

fetch('https://jsonplaceholder.typicode.com/posts?_limit=10')
  .then(r => r.json())
  .then(posts => posts.map(post => ({ ...post, avatar: `https://i.pravatar.cc/50?u=${post.userId}` })))

加上 pravatar.cc 的随机头像 API，一个有真实头像的 feed 列表就出来了。这个阶段追求的是速度，数据结构是否完全准确不重要。

第二层：接口文档对齐 → Mocky + JSON Server 本地

当接口文档基本稳定（字段名、类型、嵌套结构定稿了），我就在本地起一个 json-server（一个 npm 包，零配置跑一个本地 REST API）：

npm install -g json-server

# 在项目目录建一个 db.json
{
  "products": [
    { "id": 1, "name": "iPhone 15", "price": 5999, "status": "published" }
  ]
}

# 启动服务
json-server --watch db.json --port 3001

# 现在你就有了一个完整的 REST API
GET  http://localhost:3001/products
POST http://localhost:3001/products
PUT  http://localhost:3001/products/1

json-server 的好处是你可以完全自定义数据结构，同时支持 GET/POST/PUT/DELETE，所有增删改查的逻辑都有了。比 Mocky 稳定（因为跑在你自己的机器上），比纯硬编码更灵活（因为可以改 db.json）。

而且 json-server 还支持路由重写、过滤、排序、分页——/products?status=published&_sort=price&_order=desc 这种，真实 REST API 支持的操作它基本都有。

第三层：复杂业务逻辑 → MSW（Mock Service Worker）

当业务逻辑变复杂，简单的 Mock API 就不够用了。比如：同一个订单接口，你可能要测试"支付成功"、"支付失败"、"支付超时"、"库存不足"、"风控拦截"——这 5 种场景，每种返回的响应体完全不一样。

这时候我推荐 MSW（Mock Service Worker）。它不是简单的返回假数据，而是拦截真实的网络请求，在 Service Worker 层返回你定义的响应。前端代码完全不用改，只需要在开发环境加载 MSW 的 handler。

// handlers.js - 定义 mock 规则
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.post('/api/orders', async ({ request }) => {
    const body = await request.json();

    // 模拟不同场景
    if (body.amount > 10000) {
      return HttpResponse.json(
        { code: 'RISK_BLOCK', message: '交易金额过高，需要人工审核' },
        { status: 400 }
      );
    }

    if (body.inventory < 1) {
      return HttpResponse.json(
        { code: 'OUT_OF_STOCK', message: '库存不足' },
        { status: 409 }
      );
    }

    // 正常场景
    return HttpResponse.json({
      orderId: 'ORD-' + Date.now(),
      status: 'confirmed',
      amount: body.amount,
    });
  }),
];

这个方案的最大优势是：前端代码和 Mock 代码完全分离。前端写的是正常的 fetch('/api/orders')，到了生产环境关掉 MSW，直接走真实接口，不用改任何业务代码。

真实踩坑记录：Mocky 链接失效导致的半夜翻车

讲一个我亲身经历的教训。

2024 年底，我参与的一个海外电商项目，前端用 Mocky 搭了 30+ 个 Mock 端点。产品上线前，后端联调完成，所有接口切换到真实地址，Mocky 的那些 URL 就没人管了。

结果 3 个月后，我们要在 App 里加一个新功能，让一个新前端工程师去接一个老的 API 模块。他打开代码一看，引用了一堆 https://www.mocky.io/v3/xxxx 的地址，联调文档里只写了"这个模块的接口还没对接，你先看看代码里的 mock"。那个 mock 链接已经打不开了，代码里的 URL 形同虚设。这位新同学花了 2 天时间才搞清楚哪些接口是真的、哪些是假的。

教训：不要用线上 Mock 服务作为长生命周期的假数据源。Mocky 只适合临时 demo，不适合在项目代码里长期引用。长期 Mock 用 json-server 或 MSW，跑在自己的仓库里，跟着项目走，URL 变了代码里改，不存在链接失效的问题。

最终推荐：按项目阶段选工具

写在最后

Mock API 不是一个"能用就行"的东西，它的质量直接影响前端开发体验和联调效率。我见过太多项目因为 Mock 数据不真实、不稳定，导致前端在联调的时候大量返工。

一个好的 Mock 方案应该满足三个标准：数据结构真实（字段名、类型和真实接口完全一致）、响应场景完整（正常/错误/边界都要覆盖）、稳定性有保证（不会莫名其妙挂掉或链接失效）。

这三个标准按优先级排序的话，稳定性 > 数据结构真实 > 响应场景完整。如果 Mock 动不动就 500，它的"质量"毫无意义。

如果你是刚入门 Mock 开发，Free API Hub 上的 Mock API 分类收录了几个我上文提到的服务，都有完整的端点格式说明和调用示例，可以直接拿来练手。

好的开发体验，从好的 Mock 开始。别让"接口还没好"成为前端进度的拦路虎。