Mock回放核心机制：录制、存储、匹配、重放四步流程详解

今天我们来聊聊Mock回放的核心机制。说实话，很多测试同学觉得Mock回放就是个黑盒子——调用了就返回数据，出错了也不知道怎么查。其实没那么神秘。

它本质上就四步：录制 → 存储 → 匹配 → 重放。听起来很简单对吧？但每一环节都可能埋坑。我过去五年排查的Mock故障里，从这四步着手定位的问题占了九成以上。搞懂它们，你就握住了排查方向。

一、录制：先抓到正确的数据

什么是录制？说白了就是先把真实服务的响应抓下来保存好。我用的是录制代理，放在客户端和目标服务之间，拦截请求→拿到响应→存下来。

这里面有几个容易出问题的地方：

• 数据不全：只录了正常响应，异常响应（比如500、超时）没录。回放模拟异常时就直接没了。
• 超时陷阱：我记得有一次录制接口超时，排查了很久才发现原来是流式响应的最后一小包数据没等到就关了连接。
• 过滤不当：请求头里的traceId、时间戳等动态字段如果不过滤，匹配时永远对不上。

我个人的习惯是：录制前先明确需要覆盖哪些场景——正常、异常、边界、高负载，至少各录一份。然后配置请求过滤器，把动态字段用通配符或正则替换掉。

// 示例：录制代理配置（简化版）
{
  "proxy": {
    "targetUrl": "http://real-service:8080/api",
    "recordMode": "ALL",
    "filters": {
      "skipHeaders": ["X-Request-Id", "Timestamp"],
      "maskFields": ["$.password", "$."]
    }
  }
}

二、存储：数据得放对地方

录完的数据怎么存？常见方案有三种：本地文件、内存数据库（如Redis）、关系数据库。选择取决于你的场景：

这里有个我踩过的坑：序列化问题。有一次录的是protobuf格式，存成JSON时字段名变小写了，回放匹配时永远找不到。所以，存储格式一定要和匹配阶段使用的序列化方案一致。我建议用录制时原始格式存储，不要在存储层做转换。

另外，存储的键设计也很关键。如果你把所有请求都存成同一个键，那匹配时根本没法区分。好的做法是用方法+URL+请求体摘要做唯一键。

三、匹配：找到最接近的那条记录

匹配是Mock回放的核心——根据当前请求找出最匹配的已录制响应。说起来容易，做起来全是细节。

匹配策略大致分为三类：

1. 精准匹配：请求的所有字段（URL、method、headers、body）必须完全一致。我用过，但很快放弃了，因为动态字段一多就全挂。
2. 模糊匹配：只匹配关键字段，忽略时间戳、随机数等无关字段。这是当前最常用的方式。
3. 正则匹配：用正则表达式匹配特定模式，适合复杂的动态字段场景。

我在项目里遇到过最大的匹配故障是什么？顺序匹配导致的失败。比如你录了A→B→C三次调用，回放时调用了A→C→B，很多Mock框架按顺序匹配就会直接返回错误。解决方案有两个：一是改用基于内容的匹配（而不是顺序匹配），二是在回放时按录制顺序严格执行。

// 模糊匹配示例（伪代码）
match(Request req, RecordedData data) {
  if (req.url != data.url) return false;
  if (req.method != data.method) return false;
  // 只比较请求体中的非排除字段
  for (field in req.body) {
    if (excludeFields.contains(field.key)) continue;
    if (field.value != data.body[field.key]) return false;
  }
  return true;
}

四、重放：把录好的响应“还”回去

匹配成功后，Mock框架就把录好的响应返回给调用方。这一步如果出问题，大概率是环境差异或依赖链导致的。

重放时的常见故障：

• 响应格式变了：比如录制的是Java对象，回放时换成了Go服务，反序列化直接就崩了。
• 超时设置不一致：录制时上游超时是5秒，回放时你只等了1秒，结果永远是超时。
• 状态依赖缺失：有些接口需要前置状态（比如先登录、先创建订单），如果不在回放前把状态补上，Mock数据再全也白搭。

我曾经在排查“回放总报空指针”故障时，发现是重放环境里的一个依赖服务没启动。那服务虽然不是被测目标，但被测代码里调用了它的初始化方法。所以，我建议在回放开始前做依赖链预检，把所有外部依赖先Mock好或启动好。