仿真环境搭建：Mock Server概念、搭建简易Mock服务、配置代理转发

好，咱们进入第二章。说实话，很多同学在接口联调时最头疼的问题就是——后端还没写好，前端没法测；前端写好了，后端接口又经常挂。嗯，这时候你就需要Mock Server了。

我个人习惯把Mock Server叫做“接口替身”。它不干真正的业务逻辑，只负责按你设定的规则返回数据。说白了，就是让前后端开发能并行跑起来，谁也不等谁。

Mock Server到底是什么？

先别急着敲代码，咱们把概念理清楚。

Mock Server是一个模拟服务。它接收HTTP请求，然后根据你配置的规则返回预设的响应。比如你定义一个接口 /api/user/info，它收到GET请求后就返回一段JSON：

{
  "code": 0,
  "data": {
    "name": "张三",
    "age": 28
  },
  "msg": "success"
}

就这么简单。但它的价值可不小——

  • 解耦开发：前端不用等后端接口写好就能开始联调
  • 模拟异常：你可以轻松模拟超时、500错误、空数据等边界情况
  • 稳定测试：不受真实环境网络波动、数据变更的影响

核心要点：Mock Server不关心业务逻辑，它只关心“请求长什么样，就返回什么数据”。

我在项目中遇到过好几次这样的情况：后端接口还在开发中，但前端已经需要展示页面了。如果没有Mock Server，前端只能写死数据，等后端好了再改——那叫一个痛苦。有了Mock，前端直接调Mock接口，等后端上线后改个baseURL就行。

搭建简易Mock服务：Flask vs FastAPI

现在咱们动手搭一个。我个人推荐用FastAPI，因为它性能好、自带文档、写起来也顺手。但如果你团队里有人更习惯Flask，那也行。我两个都讲一下，你根据情况选。

方案一：用Flask搭Mock

Flask轻量、简单，适合快速上手。先装依赖：

pip install flask

然后写一个最简单的Mock服务：

from flask import Flask, jsonify

app = Flask(__name__)

# 模拟用户信息接口
@app.route('/api/user/info', methods=['GET'])
def get_user_info():
    return jsonify({
        "code": 0,
        "data": {
            "name": "张三",
            "age": 28
        },
        "msg": "success"
    })

# 模拟登录接口
@app.route('/api/user/login', methods=['POST'])
def login():
    return jsonify({
        "code": 0,
        "data": {
            "token": "mock_token_123456"
        },
        "msg": "登录成功"
    })

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000, debug=True)

启动后访问 http://localhost:5000/api/user/info，就能看到返回的JSON了。

小技巧：Flask的debug模式会自动重载代码，你改了Mock数据后不用重启服务，很方便。

方案二：用FastAPI搭Mock

FastAPI更现代，支持异步，而且自带Swagger文档。我个人更偏爱它。先装依赖：

pip install fastapi uvicorn

写一个同样的Mock服务：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

# 模拟用户信息接口
@app.get('/api/user/info')
def get_user_info():
    return {
        "code": 0,
        "data": {
            "name": "张三",
            "age": 28
        },
        "msg": "success"
    }

# 模拟登录接口
class LoginRequest(BaseModel):
    username: str
    password: str

@app.post('/api/user/login')
def login(req: LoginRequest):
    return {
        "code": 0,
        "data": {
            "token": "mock_token_123456"
        },
        "msg": "登录成功"
    }

if __name__ == '__main__':
    import uvicorn
    uvicorn.run(app, host='0.0.0.0', port=8000)

启动后访问 http://localhost:8000/docs，你会看到自动生成的API文档页面。嗯，这个功能在联调时特别有用——前端可以直接在页面上测试接口。

注意：Mock服务只用于开发和测试环境。千万别把它部署到生产环境，否则数据全是假的，用户会骂娘的。

配置代理转发

Mock服务搭好了，但前端怎么把请求转发过来呢？这就涉及到代理转发了。

你想想看，前端代码里写的是 /api/user/info，但真实后端地址可能是 http://real-backend:8080，而Mock地址是 http://localhost:5000。总不能每次都改代码吧？

所以我们需要一个代理工具，根据条件把请求转发到不同的目标。

方式一：前端代理（以Vue为例）

如果你用Vue开发，可以在 vue.config.js 里配置代理：

module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:5000',  // Mock服务地址
        changeOrigin: true,
        pathRewrite: { '^/api': '/api' }
      }
    }
  }
}

这样前端发起的 /api/xxx 请求，都会被转发到Mock服务。等后端接口写好了，你只需要把 target 改成真实后端地址就行。

方式二：使用Nginx做反向代理

如果你需要更灵活的转发规则，或者要模拟多个后端服务，Nginx是更好的选择。我曾经在一个项目里同时Mock了三个微服务，全靠Nginx搞定。

server {
    listen 80;
    server_name mock.example.com;

    # 转发到Mock服务
    location /api/user {
        proxy_pass http://localhost:5000;
    }

    location /api/order {
        proxy_pass http://localhost:5001;
    }

    # 其他请求转发到真实后端
    location / {
        proxy_pass http://real-backend:8080;
    }
}

这样配置后，/api/user 走Mock，/api/order 走另一个Mock，其他请求走真实后端。非常灵活。

避坑指南：我曾经犯过一个错——把Mock和真实服务的端口搞混了。调试了半天才发现请求打到了Mock上，但Mock里没有这个接口，一直返回404。所以建议你在Mock接口的返回数据里加一个字段，比如 "source": "mock"，方便区分。

知识体系总览

下面这张图帮你理清本章的核心逻辑：

仿真环境搭建核心逻辑 前端应用 发送HTTP请求 代理转发 Nginx / 前端proxy Mock Server Flask / FastAPI Mock核心能力 • 模拟正常响应数据 • 模拟异常场景（超时、500） • 模拟边界数据（空、大字段） • 支持动态规则匹配 代理转发方式 • 前端devServer proxy • Nginx反向代理 • Charles/Fiddler抓包工具 • 网关层路由转发 典型应用场景 • 前后端并行开发 • 接口自动化测试 • 异常场景覆盖测试 • 演示/演示环境搭建

总结一下

这一章我们做了三件事：

  1. 理解了Mock Server的概念——它就是个接口替身，让前后端能并行开发
  2. 动手搭了Mock服务——Flask和FastAPI两种方案，你选一个喜欢的就行
  3. 配置了代理转发——让前端请求能自动路由到Mock服务，不用改代码

嗯，到这里你已经有了一个可用的仿真环境。下一章咱们会在这个基础上，把Mock数据做得更智能——比如根据请求参数动态返回不同数据，或者模拟延迟、超时等场景。到时候你会发现，Mock Server能做的事情远比你想的要多。

个人建议：刚开始做Mock时，别想着一次把所有接口都Mock完。先Mock核心接口，等联调通了再逐步补充。我见过有人花了两天时间Mock了50个接口，结果第三天后端接口改了，全部白做——得不偿失。

可可精品资料库

← 上一章 📖 返回目录 下一章 →