go条件编译在测试文件中失效，因构建约束须置于文件顶部且与测试逻辑对齐；应避免混用语法、平台后缀命名及运行时goos分支，改用接口抽象和独立平台实现文件，并确保testmain无构建约束。
Go 条件编译在测试文件里根本不起作用
因为 _test.go 文件的构建约束（build tags）必须和测试逻辑本身对齐，而很多人直接把 //go:build 放在测试函数里，或者混用 // +build 和 //go:build 两种语法，导致测试被静默跳过。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试文件名不能带
_linux.go这类后缀 —— Go 测试发现器只认*_test.go，后缀里的平台标识会被忽略 - 必须在文件顶部用
//go:build（Go 1.17+ 推荐）或// +build（兼容旧版），且前后空行要严格 - 多个条件用
&&或||拼接，比如//go:build linux && cgo，空格和运算符之间不能有错位 - 运行时加
-tags才能触发对应构建分支：go test -tags=linux，不加就默认只跑无 tag 的测试
如何让同一份测试代码在 Windows/macOS/Linux 行为不同
不能靠 runtime.GOOS 动态分支写法来“模拟”跨平台逻辑 —— 这会让测试失去可预测性，CI 上容易漏掉某平台的真实路径问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把平台相关逻辑抽成接口，比如
func getTempDir() string，然后为每个平台实现独立的getTempDir_linux.go、getTempDir_windows.go等，测试调用统一接口 - 测试文件本身保持无平台依赖，只验证接口行为；平台实现文件用
//go:build控制是否参与构建 - 避免在测试中用
os.RemoveAll(os.TempDir())这类高危操作 —— 不同系统临时目录结构差异大，Windows 下可能因权限失败，Linux 下可能误删
TestMain 被条件编译屏蔽后，初始化逻辑丢失
func TestMain(m *testing.M) 如果写在带 //go:build darwin 的文件里，那在 Linux 上跑 go test 就根本不会执行它，连 setup/teardown 都没了，但错误还不报。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
TestMain必须放在无构建约束的*_test.go文件里，否则它和它依赖的变量/函数都会被整个剔除 - 平台相关初始化逻辑拆出去，用函数变量承接：
var setupFunc func() = func() {}，再在各平台文件里覆盖赋值 - 如果必须按平台做
TestMain分支，就用runtime.GOOS判断，但注意：这会让所有平台都编译进同一个二进制，只是运行时跳过 —— 不如用构建约束干净
CGO_ENABLED=0 时，带 C 依赖的测试直接编译失败
很多跨平台测试会用到 net.InterfaceAddrs() 或 syscall 相关功能，一旦开 CGO 就隐式依赖 libc，在 Alpine 容器或 CGO_ENABLED=0 场景下直接报 undefined: syscall.SYS_IOCTL。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用 Go 标准库纯 Go 实现替代 syscall，比如用
net.Interfaces()而非直接调 ioctl - 如果真要测 C 交互，单独建
xxx_cgo_test.go文件，并加上//go:build cgo，同时 CI 中明确用CGO_ENABLED=1 go test -tags=cgo - 别在
go.mod里写replace强制替换 syscall 包 —— 这会导致不同平台行为不一致，且 Go 1.20+ 已限制部分 replace 场景
跨平台测试最麻烦的不是写多几份代码，而是构建约束和运行时环境的错位 —— 一个 //go:build 写错位置，整组测试就消失得无声无息。
