自动化测试跑通不等于真测了修改代码，需确认测试与被测代码同包、无排除性构建标签、跨模块调用路径覆盖到位，并通过 go list 验证包加载。
模块开发中自动化测试能跑通，不等于它真在测你改的代码——关键要看测试是否加载了你的模块、是否覆盖了跨模块调用路径、是否被构建标签意外排除。
go test 为什么找不到你的模块测试
go test 默认只扫描当前目录（含子目录）下、与主模块同名包的 _test.go 文件。如果你把测试写在 ./tests/ 或 ./integration/ 这类独立目录里，且该目录声明的是 package integration，那 go test ./... 根本不会加载它。
- 确保测试文件和被测代码在同一个
package下（例如都是package mymodule），哪怕物理路径不同 - 避免在测试文件顶部加
//go:build !test或其他排除性构建标签——除非你明确想跳过它 - 用
go list -f '{{.Name}} {{.GoFiles}} {{.TestGoFiles}}' ./mymodule验证：输出里是否同时包含你的.go和_test.go文件 - 若模块路径是
github.com/you/repo/mymodule，则运行测试应为go test ./mymodule，不是go test ./mymodule/...（后者会递归进子模块，可能误触 vendor）
跨模块调用的测试怎么写才不假通过
当你的模块 A 依赖模块 B 的某个函数，而 B 又是本地 replace 的开发中模块（如 replace github.com/you/b => ./b），测试容易“看似通过”，实则没走真实逻辑——因为 go test 编译时可能仍用了缓存里的旧 B 版本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次改完 B 模块后，先在 B 目录下运行
go test -v ./...确保它自身通过 - 在 A 的测试中，不要只检查返回值；加一行
t.Log("using b version:", b.Version())（前提是 B 暴露了版本标识），确认加载的是你刚改的代码 - 如果 A 的测试需要启动 B 提供的真实服务（如 HTTP handler），别用
http.Get("http://localhost:8080")——改用httptest.NewServer启动 B 的 handler，再发请求 - 避免在测试里写
os.Exit(1)或直接 panic，否则go test会中断，后续断言不执行，覆盖率统计也中断
覆盖率不准？大概率是构建标签或包加载问题
go test -cover 报出 95% 覆盖率，但你新加的 linux 分支逻辑完全没被计入——这是因为覆盖率统计只包含实际被 go test 加载并执行的源文件。
- 检查被测代码里是否有
//go:build linux，而你的测试运行在 macOS 上且没加-tags=linux；此时该文件根本没编译进测试二进制，自然不统计 - 测试文件本身不能带构建标签来控制“是否参与覆盖率”；它的作用只是“是否被加载”，一旦加载，里面调用的所有路径都会被统计
- 运行
go tool cover -func=coverage.out | grep -E "(mymodule|total)"，看函数级覆盖里有没有你新增的函数名；没有就说明它没被加载 - CI 中统一用
GOOS=linux go test -covermode=count -coverprofile=coverage.out ./mymodule，避免本地环境差异干扰
最常被忽略的一点：模块测试不是“写完 _test.go 就算完”，而是要确认 go list 输出里它和被测代码在同一个包上下文中被解析——否则你写的每个 t.Run 都像在真空里运行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
