在前端开发中，Mock 数据 是提升开发效率、解耦前后端协作的重要手段。
尤其在 后端采用微服务架构 时，一个完整的业务流程往往需要请求多个服务（如用户、订单、日志、AI 等），
这时 Mock 数据就变得更复杂，也更有必要系统地去设计。

一、前端 Mock 数据的基本要求

结合实际开发经验，我认为前端 Mock 系统要满足以下几点：

1. 尽量少地修改业务代码
   Mock 功能应该在请求全局封装的地方(如: request.ts)层解决，而不是侵入业务逻辑。

2. Mock 数据独立于项目
   不建议直接在前端代码中维护 JSON，最好使用 Apifox / YApi 之类的在线 Mock 工具，方便管理与复用。

3. 支持仅 Mock 某一个接口
   当你只想临时 Mock 某个接口时，其他接口应仍然请求真实后端。

4. 兼容微服务架构
   支持针对某一个服务（比如 order、user、ai）下的某个接口单独 Mock。

二、我的实践方案（适用于中小型项目）

对于中小型项目或个人开发者，我的最佳实践是：

实现思路

1. 在 request.ts 中增加 useMock 字段
   当接口配置中存在 useMock: true 时，请求将被定向到 mock 服务地址。

2. 通过 Apifox 管理 Mock 数据
   每个项目在 Apifox 中新建独立目录，维护自己常用接口的 Mock 数据，方便复用与归档。

3. 针对单接口控制 Mock
   只要在调用时配置 useMock: true，即可单独拦截该接口，而不会影响其他真实请求。

4. 保留最小侵入性
   只需修改请求封装，不动业务逻辑；
   Mock 逻辑在合并代码前也可轻易删除，不影响上线版本。

// requet.ts
// 示例：在请求封装中增加 useMock 控制
function request<T>(config: AxiosRequestConfig & { host?: string; useMock?: boolean }) {
  if (config.useMock) {
    config.baseURL = mockHostMap[config.host || 'default']
  } else if (config.host) {
    config.baseURL = hostMap[config.host || 'default']
  }

  return instance.request(config)
}

这样，一个单独接口就可以这样 Mock：

export const getUserInfo = (data = {}) => {
  return request({
    method: 'post',
    host: 'user',
    url: '/userInfo',
    data,
    useMock: true
  })
}

三、为什么这个方案适合中小型项目

• 不依赖 CI/CD 流程：不需要自动化同步或额外配置。

• 对权限要求低：普通开发者无需修改团队脚手架或后端配置。

• 方便移除：在合并前只需删掉 useMock 字段即可恢复真实请求。

• 开发效率高：尤其在接口频繁变动、后端未准备好的阶段，能快速自测 UI 流程。

适用场景：

1. 自研小项目；

2. 外包或外部协作项目；

3. 团队未建设统一 Mock 平台；

4. 个人快速迭代或做 demo。

四、企业级 Mock 最佳实践（适用于大型团队）

如果你是项目的系统架构师、Tech Lead，或者在搭建新项目，
那就可以考虑把 Mock 逻辑纳入整个前端架构体系。

大型互联网公司的常见实践包括：

1. 使用 YApi / Apifox 统一管理接口文档与 Mock 数据

   • Mock 数据与接口定义绑定；

   • Mock URL 可自动生成；

   • 支持接口版本管理与字段校验。

2. 在 CI/CD 流程中自动同步 Mock 数据
   Mock 数据作为“契约测试”的一部分，保持与后端定义一致。

3. request 层统一控制 Mock 开关

   • 可全局切换 mock 环境；

   • 可通过 URL 参数（如 ?mock=true）临时启用；

   • 可按 host / service / path 粒度匹配 Mock。

4. 版本控制与协作机制

   • Mock 数据版本化；

   • 开发与测试环境隔离；

   • 支持团队成员协作维护。

五、总结

如果你是一位刚入行的前端开发者，Mock 数据其实是提升你开发独立性和调试效率的关键技能。
在没有权限改动架构、没有统一 Mock 平台的情况下，
用最小的代价为自己创造一个高效的开发环境，是完全正确的选择。

但如果你有机会参与项目架构设计，那就要提前规划好 Mock 流程，
让它成为团队协作的一部分，而不是个人的权宜之计。

💡 Mock 数据不是权宜之计，而是开发效率的放大器。
优秀的前端开发者，既要能写好业务代码，也要懂得如何优雅地模拟“后端世界”。