replace 是实现测试依赖隔离的唯一可靠方式，它在 go.mod 中直接重定向 import 路径，使 go build 和 go test 均生效；本地 mock 包须含完整模块路径（含 go.mod），测试专用依赖应仅 require 不加构建标签，_test.go 必须与被测代码同 module，internal/ 适合放测试辅助代码，go test -mod=readonly 应用于 ci 以确保一致性。
go.mod 中 require 和 replace 如何配合实现测试依赖隔离
开发时用真实第三方库，测试时想换成本地 mock 实现？replace 是唯一可靠方式。它在 go.mod 中直接重定向 import 路径，让 go build 和 go test 都生效，比仅改 import 路径或临时修改 GOPATH 更稳定。
-
replace github.com/real/db => ./mock/db：本地 mock 包必须有完整模块路径（含go.mod），否则go mod tidy会报错 - 测试专用依赖（如
github.com/stretchr/testify）应只出现在require块中，不加// +build test标签——Go Modules 不识别构建标签，该标签只影响go build的文件筛选 - 避免在
replace中指向未初始化的目录；执行go mod init mock/db后再go mod tidy，否则go list -m all会失败
测试专用包是否该单独建 module？
不该。Go 没有“测试 module”概念，_test.go 文件必须和被测代码在同一个 module 内，且共享同一份 go.mod。强行拆成独立 module 会导致：import 路径冲突、go test 找不到被测包、go mod vendor 无法正确拉取依赖。
- 测试代码复用逻辑（如通用断言函数）可提取为内部包，例如
internal/testutil，但仍在主 module 下，不另起go.mod - 若需跨 module 复用测试工具，应发布为独立 module（如
github.com/yourorg/testkit），再通过require引入，而非本地 replace -
internal/目录下的包天然禁止被外部 module import，适合放测试辅助代码，无需额外权限控制
go test -mod=readonly 和 -mod=mod 的实际影响
这两个参数决定 go test 过程中是否允许修改 go.mod 或 go.sum。默认是 -mod=readonly，即只读模式；CI 环境必须用它，否则 go test 可能意外写入 go.sum 导致构建不一致。
-
go test -mod=mod会自动运行go mod download并更新go.sum—— 仅应在本地开发调试新依赖时手动触发，不可提交到 CI 脚本 - 若测试中动态 import 了未声明的包（比如反射加载），
-mod=readonly会直接报错missing required module，此时应先go get显式添加依赖，而非绕过校验 -
go mod verify应作为 CI 最后一步，验证go.sum未被篡改；它不检查go.mod是否最新，只校验 checksum
表格驱动测试里如何安全注入 mock 依赖
表格驱动测试本身不处理依赖注入，但结合构造函数注入 + 接口隔离，就能让每个测试用例使用不同 mock 实例，避免状态污染。
- 被测结构体必须通过构造函数接收依赖接口（如
NewService(repo UserProvider)），不能在方法内 new 实例 - 测试表中每个
tc字段可包含一个匿名字段repo UserProvider，并在循环中传入NewService(tc.repo) - 不要在
for循环外创建 mock 实例并复用——Go 测试并发执行，多个t.Run子测试共享同一 mock 会导致调用计数混乱 - mock 实现若含状态（如计数器），应在每个子测试开始前重置，或直接 new 一个新实例
sync.Map）通常无需 mock，而 HTTP client、DB driver、时间相关操作（time.Now()）几乎总是要隔离。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
