Go测试默认不保证执行顺序，按函数名字典序运行但非规范承诺；应通过TestMain做全局初始化/清理，用t.Run组织单测内步骤，避免依赖命名或睡眠等伪顺序手段。
Go 的 go test 默认不保证测试函数的执行顺序，它按包内测试函数名的字典序运行（例如 TestA 先于 TestB），但这不是语言规范承诺的行为，也不适用于需要严格依赖顺序的场景。真正可控的“顺序执行”不能靠命名约定，而要靠设计——避免依赖顺序，或用显式控制手段隔离依赖。
理解 Go 测试的默认行为
Go 测试框架本身不提供 --run-order 或类似 flag。所有测试函数在同一个包中是并发、无序启动的（除非加 -p 1 限制并行度，但依然不保证调用次序）。即使你写成 Test01_Init、Test02_Run、Test03_Cleanup，也只是字典序巧合，且易被重构破坏。
- 测试函数应彼此独立，能单独运行、重复运行、乱序运行
- 包级
TestMain是唯一可控制全局执行流程的入口点 - 子测试（
t.Run）内部可顺序执行，但父测试之间仍无序
用 TestMain 显式编排关键流程
当确实需要初始化 → 多个测试 → 清理的线性流程（比如启动临时服务、加载配置、关闭资源），应使用 func TestMain(m *testing.M) 统一调度。
- 在
TestMain中手动调用初始化逻辑（如setup()） - 用
code := m.Run()执行所有其他测试（它们仍按默认方式运行，但已处于初始化后环境） - 在
defer cleanup()或os.Exit(code)前执行清理 - 注意：不要在
TestMain中直接调用具体测试函数（如TestDBConnect），那会绕过测试框架的计时、输出和失败统计
用子测试（t.Run）组织逻辑顺序组
若一组验证必须前后衔接（例如“创建用户 → 更新用户 → 查询用户 → 删除用户”），把它们写成一个顶层测试里的多个 t.Run 子测试：
立即学习“go语言免费学习笔记（深入）”；
- 子测试自动顺序执行，支持嵌套、跳过、并行控制（
t.Parallel()要谨慎） - 每个子测试有独立名称和生命周期，失败不影响后续子测试运行（除非用
t.Fatal） - 示例：
func TestUserLifecycle(t *testing.T) { t.Run("create", ...) ; t.Run("update", ...) }
避免伪顺序：不用命名/注释/睡眠来“控制”顺序
以下做法不可靠，也不符合 Go 测试哲学：
- 靠函数名前缀（
Test01_/Test02_）试图控制顺序 —— 字典序非保障行为，且让测试难以归类和查找 - 在测试中加
time.Sleep等待其他测试完成 —— 并发下毫无意义，还拖慢整体测试速度 - 用全局变量或包级状态在测试间传递数据 —— 导致测试相互污染，
go test -race可能报竞态，且-count=2时行为异常
基本上就这些。Go 鼓励的是“每个测试自包含”，顺序管理不是靠调度器，而是靠结构设计：用 TestMain 做跨测试的环境准备，用 t.Run 做单测试内的步骤编排。不复杂，但容易忽略本质。
