Go测试需启用Modules并初始化模块：执行go env -w GO111MODULE=on，mkdir myproject && cd myproject && go mod init example.com/myproject，测试文件名须为*_test.go且Test函数签名正确。
确认 Go 安装是否满足测试需求
本地 Go 测试环境的核心是 go test 命令能否正常运行，而不是单纯“能跑 Hello World”。常见误区是只验证 go version 成功，却忽略 GOPATH、Go Modules 和 GOROOT 的协同问题。
- 运行
go env GOPATH查看工作区路径，若为空且未启用 Modules（GO111MODULE=off），go test可能找不到包 - 推荐始终开启 Modules：执行
go env -w GO111MODULE=on，避免依赖 GOPATH 目录结构 -
GOROOT通常无需手动设置，但若使用多版本 Go（如 viagvm或asdf），需确保which go指向预期版本
初始化一个可测试的模块目录
Go 1.11+ 的测试必须基于 module；直接在任意目录下 go test 很可能报错 no Go files in 或 cannot find module providing package。
mkdir myproject cd myproject go mod init example.com/myproject
-
go mod init后的模块路径不一定要真实存在，但应唯一、合法（不含空格、大写字母建议转小写） - 初始化后会生成
go.mod文件，这是go test解析依赖和包路径的依据 - 若已有代码但无
go.mod，直接运行go test会退化为 GOPATH 模式，易与预期不符
编写并运行第一个测试用例
测试文件必须以 _test.go 结尾，且函数名以 Test 开头、参数为 *testing.T。名字不规范或签名错误会导致 go test 完全忽略该函数。
cat > hello.go << 'EOF'
package main
func Hello() string {
return "Hello, world"
}
EOF
cat > hello_test.go << 'EOF'
package main
import "testing"
func TestHello(t *testing.T) {
got := Hello()
want := "Hello, world"
if got != want {
t.Errorf("Hello() = %q, want %q", got, want)
}
}
EOF
go test
-
go test默认只运行当前目录下的测试；加-v可看到具体测试函数名和输出 - 若测试文件中 import 了非标准库包，
go test会自动触发go mod tidy（前提是go.mod已存在） - 不要把测试逻辑写在
main()函数里——go test不执行main，也不编译成可执行文件
常见失败场景与快速定位方式
测试失败时，go test 默认只输出失败摘要，容易漏掉关键上下文。真正卡住的往往不是逻辑，而是环境隐含约束。
立即学习“go语言免费学习笔记（深入）”；
- 报错
cannot find package "xxx" in any of ...：说明测试文件 import 的包未被go.mod记录，运行go mod tidy补全依赖 - 报错
test binary not created: failed to parse packages：通常是语法错误，用go build -o /dev/null .先验证源码可编译 - 运行
go test ./...却跳过某些子目录：那些目录下没有*_test.go，或go.mod分割了模块边界（跨 module 子目录需单独go test） - Windows 下路径分隔符导致测试失败：避免在测试中硬编码
\，统一用filepath.Join或path/filepath
模块初始化和测试命名规则是绝大多数本地测试失败的根源，比语法错误更隐蔽，也更值得花两分钟确认。
