Go Gock 并发运行测试时为什么需要隔离全局拦截状态

Go Gock 的模拟规则、默认拦截状态及部分网络配置属于包级共享状态。并发测试即使分别创建 http.Client，也可能共同匹配、消费或清空同一套规则。需要隔离的是完整生命周期：配置规则、执行请求、检查预期、结束请求以及恢复清理，而不是只避免两个 goroutine 同时调用 New。

官方地址：https://github.com/h2non/gock

我会优先把使用全局拦截的测试限制在一个受控范围内，再决定哪些用例值得并行。这个取舍是测试组织建议，不是一次实测性能结论。规则很复杂时，表面上减少几秒执行时间，却让清理时机变得不可预测，往往不利于定位失败。

独立 Client 不等于独立规则池

假设 A、B 两个测试请求相同接口，但期待不同响应。它们各自创建 Client，并不意味着规则也随 Client 分开存储。Gock 的规则注册写入包级 store；不同客户端的拦截运输层仍会访问共享匹配机制。A 的请求可能触及 B 的规则，A 的清理也可能移除 B 尚未消费的规则。

仅给每个用例换一个域名，可以减少匹配冲突，却不能隔离全局关闭、清理和网络放行设置。只有“规则不会匹配到别人”和“别人不能清理我的规则”同时成立，才接近用例隔离；域名不同只能帮助前一部分。

并发请求与并发配置是两回事

官方说明 Gock 并非完全线程安全，并建议先配置规则与客户端拦截，再启动并发代码。这支持的是有明确准备阶段的使用方式，不能扩展解释为任意用例可同时注册规则、发送请求、切换配置和 Off。

即便某些内部操作使用锁，语义污染仍然可能发生：一个操作可以在内存访问上受到保护，但它清除的恰好是另一个测试的合法规则。竞态与全局状态串扰需要分别考虑，不能把“内部有互斥锁”直接当成测试之间自动隔离。

串行管理整个配置与清理范围

下面是可保存为测试文件的原创示例，依赖 github.com/h2non/gock。它使用专用客户端，保持真实网络禁用，执行一个同步请求，再检查预期。示例未实际运行，不提供测试通过或竞态检查结果。

package api_test

import (
    "io"
    "net/http"
    "sync"
    "testing"
    "time"

    "github.com/h2non/gock"
)

// 同一测试进程中所有 Gock 用例必须遵守同一把锁。
var gockScope sync.Mutex

func TestFetchReportSerial(t *testing.T) {
    // 此用例不调用 t.Parallel，也不在并行父测试下启动。
    gockScope.Lock()
    transport := &http.Transport{}
    client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
    t.Cleanup(func() {
        defer gockScope.Unlock()
        // 此时请求已经结束，才恢复 Client 并清理包级状态。
        gock.RestoreClient(client)
        gock.OffAll()
        gock.DisableNetworking()
        gock.DisableNetworkingFilters()
        gock.Observe(nil)
        transport.CloseIdleConnections()
    })

    // 专用测试范围使用统一基线，不继承上个用例的网络放行设置。
    gock.OffAll()
    gock.DisableNetworking()
    gock.DisableNetworkingFilters()
    gock.Observe(nil)
    gock.New("https://reports.invalid").
        Get("/summary").
        Reply(http.StatusOK).
        BodyString("ready")
    gock.InterceptClient(client)

    // 规则与拦截器配置完成后才发请求。
    response, err := client.Get("https://reports.invalid/summary")
    if err != nil {
        t.Fatal(err)
    }
    data, readErr := io.ReadAll(response.Body)
    closeErr := response.Body.Close()
    if readErr != nil {
        t.Fatal(readErr)
    }
    if closeErr != nil {
        t.Fatal(closeErr)
    }
    if response.StatusCode != http.StatusOK || string(data) != "ready" {
        t.Fatalf("响应不符合预期: status=%d body=%q", response.StatusCode, data)
    }
    // 在 OffAll 清空记录之前检查本用例的预期与未匹配请求。
    if !gock.IsDone() {
        t.Error("仍有未消费的模拟规则")
    }
    if gock.HasUnmatchedRequest() {
        t.Error("存在未匹配的请求")
    }
}

锁一直持有到 t.Cleanup 完成，不只覆盖 gock.New。恢复客户端、清理全局状态后才释放它，避免下一个遵守协议的用例与当前清理重叠。锁只对同一测试进程内使用同一变量的代码有效；其他 helper 若绕过它调用 Gock，仍然可能污染状态。

示例也没有调用 t.Parallel。不能只删除当前测试中的这一行就忽视外层并行：并行父测试、共享 helper、后台任务，都需要纳入范围。若持锁的父测试等待需要同一把锁的子测试，还可能造成死锁。测试锁不是对所有测试组织方式都透明的补丁。

这里在开始和结束都设置明确的专用基线。它适用于由这组用例统一拥有 Gock 状态的测试进程，不适用于在未知业务拦截器或其他测试正在运行时强行重置全局配置。若需要保留复杂的外部状态，优先把测试边界划分清楚。

失败也必须走到可预测的清理点

清理前检查 IsDone 和未匹配请求，可以区分“规则未被请求消费”和“请求没有规则”两类问题。不能先 OffAll 再判断是否完成，因为规则与未匹配记录已经被清空，结果失去原本含义。

Off 会移除规则并关闭默认拦截；OffAll 还会清理未匹配请求记录。网络模式、过滤器和观察回调属于另一部分设置，应按用例所有权明确恢复，不要假设一个清理函数等于所有配置都回到预期基线。自定义 Client 也应使用 RestoreClient 恢复其运输层。

如果被测函数启动了 goroutine，请求必须在检查和清理前结束。用等待组、完成通道或被测接口提供的等待方法建立真实完成关系；不能靠 Sleep 猜测。否则清理可能发生在请求仍在发送时，后续用例甚至会收到前一个用例留下的请求。

必须并行时，选择真正独立的状态

我倾向于让少量复杂 Gock 场景保持串行，把适合局部替身的基础用例设计成显式注入依赖。需要进程级隔离时，CI 的任务划分也应与测试所有权对应，不能把同一进程里两个子测试称为两个隔离环境。

失败复盘记录建议包括测试名称、请求方法与路径、规则是否消费、未匹配请求是否存在、是否启用真实网络及清理前是否仍有后台请求。请求内容可能含敏感信息，不应为排错随意打印完整认证头或请求体。

单独 InterceptClient 能做到每个测试互不干扰吗？不能。它改变指定 Client 的运输层，但不代表规则池按 Client 划分。

只把 Off 放到 defer 就够了吗？只能保证该函数返回时尝试清理，不能保证其他并发用例不受这次清理影响。生命周期独占和清理动作缺一不可。

能用不同 URL 继续 t.Parallel 吗？不同 URL 有助于避免匹配重叠，但不能阻止全局清理和配置开关互相影响。需要并行时应选择与隔离目标一致的设计。

参考：Gock 官方使用与并发提示；全局拦截及清理实现；规则存储实现；运输层匹配实现。