ginkgo测试panic主因是未调用runspecs：每个_test.go文件须有唯一testxxx函数，先registerfailhandler(fail)再调runspecs(t,"suite")，缺一不可，否则框架不启动、断言不执行或panic。
Ginkgo 测试一跑就 panic，大概率是没调用 RunSpecs ——这不是 bug，是框架启动机制没走通。
为什么 go test 时 Ginkgo 直接 panic 或 silent 退出
Go 原生的 go test 不会自动识别 Describe/It 块；Ginkgo 的测试逻辑必须显式启动。漏掉 RunSpecs，整个 BDD 结构就被跳过，看起来像“没跑测试”，其实是框架根本没加载。
- 常见错误现象：
go test输出ok ./pkg 0.001s，但所有It都没执行；或 panic 报no tests to run（尤其在非main包或子模块下） - 每个测试文件（如
xxx_suite_test.go）必须有且仅有一个func TestXxx(t *testing.T) - 该函数里必须先调
RegisterFailHandler(Fail)，再调RunSpecs(t, "SuiteName")，顺序不能反 - 绝对不要在
init()、包级变量初始化、或多个TestXxx函数里重复调RunSpecs，会破坏go test生命周期
Gomega 断言失败却不报具体值，怎么修
Gomega 的 Expect(...).To(Equal(...)) 失败时只抛异常，不自动打印实际值和期望值——这依赖你注册的失败处理器是否把信息正确透传给 t.Fatal。
- 必须在
TestXxx函数内、RunSpecs之前调RegisterFailHandler(Fail)，其中Fail来自github.com/onsi/ginkgo/v2 - 别写成
RegisterFailHandler(t.Fail)：handler 执行时t不可用，会 panic - 如果用
ginkgo run命令跑，Fail默认已注册；但混用go test时这步绝不能省 - 验证方式：故意让一个
Expect("a").To(Equal("b"))失败，看输出是否含Expected<br> "b"<br>to equal<br> "a"
并发测试下 BeforeSuite 和 BeforeEach 混用导致随机失败
Ginkgo 默认并行执行 It，而 BeforeSuite 只跑一次，BeforeEach 每个 It 前都跑。错把本该隔离的资源放 BeforeSuite，就会引发状态争抢。
- 典型现象：单测全过，加
-p 4就随机失败；出现connection refused、key already exists或数据库唯一约束冲突 - 全局共享资源（如 HTTP server、DB 连接池）可放
BeforeSuite，但必须确保线程安全（例如加锁、或使用连接池自带的并发控制） - 每个测试独占资源（临时文件、
map、mock 对象、内存缓存）必须在BeforeEach里初始化，不能复用 - 避免在
BeforeSuite里赋值可变全局变量，比如var db *sql.DB，然后在It里执行db.Exec(...)改状态
最常被忽略的点：不是写了 Describe 和 It 就算“用了 Ginkgo”，而是要确保测试入口函数、Fail 注册、RunSpecs 三者完整且位置正确——少一个，整个 BDD 测试链就断在起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
