go test卡住通常不是网络慢，而是模块解析失败、replace路径错误或GOPROXY冲突导致无限等待；需检查GO111MODULE、GOPROXY、go list -m all是否正常，并确保replace在模块根目录生效且未被-mod=readonly禁用。
go test 时模块拉取卡住，根本不是网络慢
超时通常不是因为 GitHub 或 proxy.golang.org 真的连不上，而是 go test 默认不设超时，遇到私有模块解析失败、replace 路径错误或 GOPROXY 配置冲突时，会无限等待模块下载或校验。尤其在 CI 环境中，没有交互提示，看起来就像“卡死”。
- 检查
GO111MODULE=on是否生效（CI 中常被覆盖） - 确认
GOPROXY设置是否包含私有仓库代理（如https://proxy.golang.org,direct无法访问内网模块） - 运行
go list -m all验证模块图能否正常解析——若此处卡住，go test必然卡住 - 临时禁用模块校验：
GOINSECURE="your-internal-domain.com"（仅限测试环境）
本地 replace 不生效导致测试加载旧版本
你在 go.mod 里写了 replace internal/pkg => ./local-pkg，但 go test 仍去拉远程 v1.2.0 ——这是因为测试运行时未启用模块模式，或 replace 被 GOPROXY=direct 绕过。
- 确保测试命令在模块根目录执行（即存在
go.mod的路径），否则replace视为无效 - 避免在测试命令中加
-mod=readonly（它会忽略replace） - CI 中若用
go test ./...，需前置go mod download并验证go mod graph | grep local-pkg是否出现替换关系 - 调试技巧：加
-x参数看实际 fetch 命令：go test -x -v ./... 2>&1 | grep "git clone\|fetch"
第三方依赖 mock 失败引发间接超时
测试中用了 gomock 或 testify/mock 模拟外部服务，但 mock 对象未正确拦截 HTTP/gRPC 调用，真实请求发出去后因无响应而超时。这类问题常被误判为“模块问题”，实则是测试隔离失效。
- 检查 mock 初始化是否在
Test函数开头完成（例如ctrl := gomock.NewController(t)） - 确认被测代码使用的客户端实例，是否来自 mock 构造而非
http.DefaultClient或全局单例 - 对 HTTP 依赖，优先用
httptest.Server替代网络调用，避免依赖 DNS 解析或代理配置 - 给所有外部调用显式设超时：
client := &http.Client{Timeout: 200 * time.Millisecond}，防止测试 hang 住
go test -race 和模块缓存冲突
启用竞态检测（-race）时，Go 会重新编译所有依赖模块，若某模块含 cgo 或需构建本地工具链（如 github.com/mattn/go-sqlite3），且构建环境缺失 C 编译器或 pkg-config，就会卡在 build 步骤，表现为“超时”。
立即学习“go语言免费学习笔记（深入）”；
- CI 中统一设置
CGO_ENABLED=0（除非必须用 cgo） - 提前缓存模块构建产物：
go install -race std（一次预热，避免每次测试都重编） - 排查日志末尾是否出现
building ... with cgo或exec: "gcc": executable file not found - 对纯 Go 依赖，可用
go test -race -gcflags="-l" ./...跳过内联优化，减少构建压力
真正卡住的地方，往往不在你写的测试代码里，而在模块解析阶段或 mock 初始化之后那一毫秒的真实网络调用里。先跑 go list -m all，再看 go test -x 输出，比反复改超时时间更省时间。
