导语：
流量回放的价值，是把真实业务请求变成可重复的回归素材；团队最担心的却是回放过程本身：订单会不会重复写入？支付和短信会不会真的发出去？消息会不会被下游消费者再次处理？
解决这个问题，不能只在测试环境外面加一层“沙箱”口号，而要在调用发生的位置区分两种动作：业务入口需要真实执行，数据库、HTTP/RPC、缓存和消息生产等下游子调用则应在已配置、已命中的范围内返回录制结果。下面从 JVM 调用拦截、Mock 匹配和证据留痕三层说明这条链路。
1. 回放真正危险的地方，不是入口请求
一条下单请求可能依次执行以下动作：
POST /api/order/create ├─ 写入 orders / order_items ├─ 调用库存服务扣减库存 ├─ 调用支付或风控接口 └─ 向 Kafka / RocketMQ 发送订单事件如果只把入口请求复制到测试环境，却让这些下游调用继续访问真实资源，回放就可能重复写数据、重复扣款、重复发短信，甚至触发真实消费者。传统 Mockito、WireMock 需要团队逐个维护桩和返回值，业务分支一变，桩也要跟着变。
Softprobe 的录制回放链路把“入口真实执行”和“下游返回录制结果”拆开处理。这个拆分是安全边界的核心，后续每个依赖类别都要有自己的命中记录和验证证据。
2. JVM 字节码拦截：不改业务代码，识别入口与子调用
接入 Java Agent 的方式很轻量，业务代码不需要增加测试分支：
java-javaagent:/opt/softprobe/sp-agent.jar\-Dsp.app.id=order-service\-Dsp.api.url=http://sp-backend:8090\-jarorder-service.jarAgent 在类加载或运行时对已支持的调用点织入拦截逻辑。产品实现中，入口类别和下游类别有明确区分：Servlet、Gateway、任务和消息消费可以作为业务入口；HTTP Client、JDBC、Redis、RPC 和 MQ Producer 属于下游依赖。下面代码是帮助读者理解机制的原理示意，不是对外承诺的源码 API：
Objectinvoke(Invocationinvocation){if(ReplayContext.isEntryPoint(invocation)){returninvocation.proceed();// 入口：让业务代码真实执行}if(ReplayContext.isReplay()&&MockMatcher.hit(invocation.category(),invocation.operation(),invocation.args())){returnMockStore.recordedResult(invocation);// 子调用：返回录制结果}returnReplayFallback.handle(invocation);// miss 时按协议策略显式处理}这里有三个必须说清楚的边界：
- “不改业务代码”不等于“不需要配置”。应用、依赖类型、采样范围和 Mock 策略仍需配置。
- “自动 Mock”不等于“所有第三方调用都天然安全”。未支持、未录制或明确配置为透传的调用，必须单独做环境隔离和验证。
- Mock 命中要留下记录。只看到入口返回 200，不能证明数据库写入被拦截，也不能证明消息没有发到真实 Broker。
3. 三类高风险子调用如何隔离
3.1 数据库写操作：返回录制时的影响行数，不执行真实写入
业务代码可能调用 JDBC 或 ORM 执行INSERT、UPDATE、DELETE。录制时可以保存 SQL 特征、参数和影响行数；回放时在命中的前提下直接返回录制结果：
// 业务代码示意intaffectedRows=statement.executeUpdate(sql);// Agent 拦截逻辑示意：回放 miss 也不落真实 JDBCif(ReplayContext.isReplay()){MockResultmock=MockStore.replay("DATABASE",sql,params);returnmock.hit()?mock.affectedRows():0;// 安全默认值，省略异常/策略分支}returninvocation.proceed();// 录制或普通运行路径这样，订单服务仍然会执行“写库成功后继续发消息”的业务分支，但真实测试库不会因为本次回放新增一条订单。发布前应同时检查数据库审计日志、回放侧 Mock 命中数和异常分支；否则“接口通过”仍可能掩盖写入没有被拦截的情况。
3.2 支付、短信、风控等外部 API：返回录制快照，不触发真实副作用
对 HTTP Client、Feign、RestTemplate、gRPC 等已接入调用，回放可以依据操作名和请求特征匹配录制快照：
HttpResponsecallPayment(PaymentRequestrequest){if(ReplayContext.isReplay()){HttpResponserecorded=MockStore.replay("HTTP_CLIENT",request);if(recorded!=null)returnrecorded;thrownewReplayMockMissException(request);// 不因 miss 放行真实支付请求}returnrealPaymentClient.call(request);}请求体中的订单号、时间戳或签名如果每次都会变化，必须先配置匹配容差或动态字段规则。匹配失败时，默认更安全的行为是将回放标记为 Mock miss；只有在隔离网关、专用账号和可回收数据都准备好时，才考虑透传。
3.3 消息生产：隔离 Producer，防止重复消费和链路污染
Kafka、RocketMQ、RabbitMQ 等 Producer 的风险不在当前接口响应，而在消息被真实消费者拿到以后会继续扣库存、发通知或更新状态。回放命中后只返回录制时的发送结果：
SendResultsend(Stringtopic,byte[]payload){if(ReplayContext.isReplay()){SendResultrecorded=MockStore.replay("MESSAGE_PRODUCE",topic,payload);returnrecorded!=null?recorded:MockStore.suppressedMiss();// miss 也不落到真实 Broker；具体 ack/异常由协议适配器决定}returnproducer.send(topic,payload);}验证这条隔离链路时，不要只看回放报告；还要检查测试 Broker 的生产记录、消费者组 offset 和 Mock 命中日志，确认没有消息越过隔离边界。
4. 一张图看懂“入口真实执行、子调用返回快照”
图中最容易被忽略的是 G：Mock miss 不能被默默当成通过。实际发布时要把“录制覆盖范围、Mock 命中、透传清单、未验证依赖”一起展示，才能判断这次回放是否真的安全。
5. 如何把“零数据污染”变成可验收的结果
建议用一条最小验收清单替代口头承诺：
| 验收项 | 要看到的证据 |
|---|---|
| 入口真实执行 | 入口请求、响应、trace 与回放报告一致关联 |
| 数据库写隔离 | JDBC/ORM Mock 命中、影响行数返回；数据库审计无真实写入 |
| 外部 API 隔离 | HTTP/RPC Mock 命中；支付、短信或风控网关无真实调用 |
| MQ 隔离 | Producer Mock 命中；测试 Broker 和消费者组无重复业务消息 |
| Miss 可见 | 回放报告显示 Mock miss/缺失依赖，并进入失败或待核查状态 |
| 环境兜底 | 即使存在未 Mock 依赖，也使用专用账号、隔离网络和可回收数据 |
在此基础上，运营材料可以继续承接 Softprobe 的三个产品卖点：用批量回放支撑大规模回归，用入口与依赖清单做可审计覆盖，用 AI 将 Mock miss、差异和日志串成诊断证据。所谓“100%业务场景覆盖”，应写成“在明确的业务入口、出站依赖和回放计划分母内完成 100% 审计覆盖”，并附covered/skipped/blocked数量。
