Go test 默认禁用CGO，需设CGO_ENABLED=1；C内存管理易致use-after-free；go tool cover不统计C代码；Windows下须统一MSVC或MinGW工具链。
Go test 跑不起来 CGO 代码？先确认 CGO_ENABLED 环境变量
Go 单元测试默认禁用 CGO，哪怕源码里写了 #include <stdio.h> 或调用了 C.malloc，go test 也会静默跳过相关文件，甚至不报错——只显示 “no buildable Go source files”。
必须显式开启：
- 运行测试前设
CGO_ENABLED=1，例如：CGO_ENABLED=1 go test -v - 若用
go run或构建二进制，同样要加这个环境变量，否则链接阶段失败 - 交叉编译时（比如从 macOS 编译 Linux 二进制），
CGO_ENABLED=0是默认行为，此时带 CGO 的测试根本不会被编译，别误以为是代码问题
测试里调用 C 函数返回空指针？检查 C.CString 和内存生命周期
CGO 中最常踩的坑不是语法，而是 C 内存和 Go GC 的边界模糊。比如写了个测试：
func TestFoo(t *testing.T) {
cStr := C.CString("hello")
defer C.free(unsafe.Pointer(cStr))
ret := C.some_c_func(cStr)
// ... 断言 ret
}
看似没问题，但若 some_c_func 内部保存了 cStr 的指针并异步使用，测试就可能 panic：Go 的 defer 在函数退出时才释放，而 C 函数可能在它返回后还访问那块内存。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要假设 C 函数“立即用完”参数；查清它的文档或源码，看是否要求调用方长期持有内存
- 若需长期有效字符串，改用
C.CBytes+ 手动管理，或在 C 侧用strdup复制 - 测试中避免复用同一块 C 内存做多次调用，尤其并发测试时容易触发 use-after-free
覆盖率统计漏掉 .c 文件？go tool cover 本身不支持 C 代码
Go 官方 go test -cover 只统计 Go 源码行覆盖，对 .c、.h 或内联 C 代码完全无感知——哪怕你在 import "C" 下写了 200 行 C，覆盖率报告里也永远显示 0%。
- 想测 C 部分逻辑，得用 C 侧工具链：比如用
gcov编译 C 代码（加-fprofile-arcs -ftest-coverage），再配合lcov生成报告 - Go 测试启动 C 逻辑时，可加日志或全局计数器（如
var cFuncCalled int），在测试末尾断言该变量值，作为间接覆盖验证 - CI 中若强制要求“整体覆盖率 >80%”，记得把 C 部分单独剔除，否则永远达不到——这不是你代码的问题，是工具链限制
Windows 上跑 CGO 测试失败？MinGW 与 MSVC 工具链不兼容
Windows 下 CGO 默认走 MSVC（需要安装 Visual Studio 或 Build Tools），但很多人装了 MinGW 并设了 CC=gcc，结果测试编译失败，报错类似：undefined reference to `__imp__invalid_parameter_noinfo'。
- Go 对 Windows CGO 严格绑定工具链：MSVC 对应
cl.exe，MinGW 对应gcc.exe，二者 ABI 不通，不能混用 - 检查当前生效的编译器：
go env CC，再运行$env:CC（PowerShell）或echo %CC%（CMD）确认环境变量没被覆盖 - 如果必须用 MinGW（比如依赖某个仅提供 MinGW 编译的 .a 库），得统一整个构建链：设
CC=gcc、CXX=g++，且确保所有 C 依赖都用同版本 MinGW 编译，否则链接时符号找不到
CGO 测试真正的复杂点不在语法，而在三重边界交叠：Go 的内存模型、C 的手动管理、以及不同平台工具链的隐式约定。一个 free 忘了调，或一个环境变量设错，测试就能通过但线上崩——这种问题往往只在特定 OS 或压力下暴露。
