1. Mock 回放基础：从概念到实战

我记得第一次接触 Mock 这个词，是在 2014 年做一个大改版项目的时候。
联调环境死活连不上，后端说要等三天才能部署测试。
当时团队里一位老大哥丢过来一句话：“你先把接口 Mock 掉，别等着。”
就这么一句话，开启了我跟 Mock 的十年缘分。

1.1 到底什么是 Mock？

Mock 这个概念，说白了就是“造一个假货，以假乱真”。

在 Android 开发里，当我们依赖的服务、设备、数据源还没准备好，或者不稳定时，我们会先造一个“替身”出来。
这个替身能返回我们想要的数据，也能模拟各种极端情况——超时、报错、空数据。

举个例子：

// 真实接口，需要后端配合
interface UserApi {
    @GET("user/info")
    suspend fun getUserInfo(): UserInfo
}

// Mock 替身，完全本地自己编数据
class MockUserApi : UserApi {
    override suspend fun getUserInfo(): UserInfo {
        return UserInfo(
            id = 10086,
            name = "测试用户",
            avatar = "https://mock.avatar/1.png"
        )
    }
}

你想想看，这段代码在真实联调时可以直接替换成 Mock 实现，
不用等后端、不用配 Wi-Fi、甚至飞机上都可以跑完整流程。
这就是 Mock 最朴素的用途——解耦依赖，让你专注于自己的代码逻辑。

1.2 回放又是什么？

Mock 解决了“能不能跑”的问题，但离“跑得对不对”还有段距离。
你想想看：你造了一个 Mock 接口，每次返回都一样的数据。
那遇到线上 bug 怎么办？某个接口突然返回了错误码，你本地能复现吗？

这时候就需要 回放（Replay） 了。

回放的思路很简单：
把线上真实流量里的请求-响应记录下来，存成一个文件（我们叫它 Mock 文件 或 回放数据包）。
然后在本地开发或测试时，用这个文件代替真实的网络请求。
这样你测试的数据就是真实的线上数据，而不是你自己拍脑袋编的。

举个例子：用户反馈某个页面闪退，你查日志发现是某个字段为空。
但本地 Mock 那个字段一直有值，你复现不了。
这时你把线上那个请求录下来，直接回放，bug 瞬间复现。
—— 这种做法，我在好几个项目里救过急。

1.3 核心概念梳理

为了方便后续深入，我们先统一三个基本概念：

1.4 应用场景

以下是我在多个项目中总结出的三个最实用的场景：

1. 独立开发阶段： 后端接口还没写好，或者部署环境不稳定。
   先用 Mock 数据跑通 UI 和业务逻辑，不依赖任何外部服务。
2. Bug 复现： 线上出现偶发 bug，日志不完整。
   把当时的请求录下来，在本地回放，用 Debugger 一步步看数据流。
3. 自动化测试： 单元测试和 UI 测试中，需要可重复、可预测的输入数据。
   回放数据能保证每次运行结果一致，避免环境差异导致的误报。

举个例子，我最近参与的支付流程重构项目：
支付回调的订单状态有十几种，如果手写 Mock 数据，要写十几个 if-else。
而我们直接录了线上 2000 笔真实订单的回调，做成回放数据包，
一行代码就覆盖了所有分支，还发现了一个文档里没写到的“订单取消中”状态。

1.5 知识体系总览

讲到这里，我把本章的知识结构画成一张图，方便你整体把握：

1.6 为什么我说 Mock 回放值得系统学习？

我做过的项目里，超过一半的线上 bug 是因为数据跟本地 Mock 对不上导致的。
比如本地 Mock 永远返回 200，线上突然返回 502，你的错误处理分支根本没测试过。
—— 这都是血淋淋的教训。

而回放正好解决了这个问题：
它让你可以用真实态数据测试，又不需要真的连着线上环境。

你想想看，如果你能把线上某次崩溃的请求原样回放到本地，
结合 Android Studio 的 Debugger，一行一行看数据怎么被处理的……
那种“破案”的快感，是纯 Mock 永远给不了的。