go test需确保模块初始化、测试文件以_test.go结尾、函数名以Test开头且参数为*testing.T；推荐表格驱动测试、接口抽象mock外部依赖，并注重边界覆盖与可维护性。
go test 命令怎么用才不踩坑
很多人写完函数就 go run main.go 看输出，但真正可靠的验证得靠 go test。它不是“运行测试文件”那么简单——默认只跑当前包下以 _test.go 结尾的文件，且只执行以 Test 开头、参数为 *testing.T 的函数。
- 常见错误：把测试逻辑写在普通
.go文件里，或函数名写成testAdd（缺大写T），go test直接静默跳过 - 必须加
go mod init初始化模块，否则go test可能报no Go files in current directory（即使有_test.go） - 想看详细过程？加
-v参数：go test -v；想测覆盖率？go test -coverprofile=coverage.out && go tool cover -html=coverage.out
如何写可维护的测试函数
Go 测试不是拼 t.Log 数量，核心是“隔离 + 断言 + 清理”。比如测试一个 HTTP handler，别直接 http.ListenAndServe，而要用 httptest.NewRecorder() 模拟响应。
- 每个
TestXxx函数应独立：不依赖全局变量、不共享状态；用t.Cleanup注册清理动作（如删临时文件、关闭 mock DB 连接） - 避免硬编码预期值；对结构体比较，优先用
reflect.DeepEqual而非逐字段if a.X != b.X（但注意它不处理 unexported 字段） - 边界值必须覆盖：空输入、负数、超长字符串、nil 指针——这些地方最容易 panic 却被忽略
table-driven test 怎么组织才清晰
Go 社区强烈推荐表格驱动测试（table-driven test），尤其适合参数组合多的函数（比如 JSON 解析、校验规则）。它把测试用例抽象成结构体切片，主逻辑只写一遍，避免重复代码。
- 结构体字段命名要直白：
name（用例名）、input、wantErr、want，别用tc或tt这类缩写 - 用
t.Run(name, func(t *testing.T) { ... })包裹每个子测试——这样失败时能精准定位是哪个 case 崩了，而不是笼统报 “TestParse failed” - 别把测试数据塞进代码里；复杂数据建议放
testdata/目录，用os.ReadFile("testdata/case1.json")读取，便于复用和版本管理
测试外部依赖（DB/HTTP/API）该 mock 还是集成？
真实调用 MySQL 或第三方 API 会让测试变慢、不稳定、难并行。Go 没有像 Java 那样的强大 mock 框架，但有更轻量的解法：接口抽象 + 依赖注入。
- 把 DB 操作封装进接口（如
type UserRepository interface { GetByID(id int) (*User, error) }），测试时传入内存实现（map 模拟）或sqlmock库 - HTTP 客户端测试：用
http.ServeMux+httptest.NewUnstartedServer启一个假服务，比 patchhttp.DefaultClient更可靠 - 慎用
os.Setenv修改环境变量——它影响整个进程，多个测试并行会冲突；改用t.Setenv（Go 1.17+），自动恢复
测试最难的不是语法，而是判断“这里值不值得测”和“这个边界我有没有漏”。很多人在写完业务逻辑后补测试，结果发现函数耦合太重、无法隔离——这时候倒逼重构比硬写 mock 更有效。先让代码可测，再让测试可读，最后让覆盖率有意义。
