Go build tags 必须紧贴//go:build或// +build且前后有空行，推荐用支持布尔表达式的//go:build新语法；平台相关代码应拆分到独立文件并打对应tag，避免单文件内用runtime.GOOS分支；go test需显式加-tags参数才识别tag，CI中应组合GOOS与-tags验证多平台编译。
Go build tags 怎么写才生效
build tags 不是注释，也不是随便加的字符串，它必须紧贴 //go:build 或旧式 // +build，且前后有空行。漏掉空行、写错大小写、放错位置（比如写在包声明后），go build 就直接忽略——你改了代码却没生效，八成卡在这儿。
推荐统一用新语法 //go:build，它支持布尔表达式，也更严格：
//go:build linux || darwin // +build linux darwin package main
-
//go:build行必须紧跟文件开头，前面不能有任何非空行（包括空格） - 后面必须跟一个空行，再接
package声明 - 多个条件用空格分隔（
linux amd64表示同时满足），用||表示或，!表示非 - 旧式
// +build仍可用，但不支持||和!，容易误判
怎么让不同平台走不同实现文件
最干净的做法是：把平台相关逻辑拆到独立文件里，每个文件顶部打上对应 build tag，Go 编译器自动按需加载。别试图在一个文件里用 runtime.GOOS 切分支——那会把所有平台代码都编译进去，增大二进制体积，还可能触发未预期的初始化。
例如实现跨平台临时目录路径：
立即学习“go语言免费学习笔记（深入）”；
-
temp_linux.go开头写//go:build linux -
temp_darwin.go开头写//go:build darwin -
temp_windows.go开头写//go:build windows - 它们都定义同名函数
getTempDir()，返回string
调用方只 import 包、调用 getTempDir()，完全不用管哪个文件被编译进来。Go 工具链保证同一构建中最多一个文件满足 tag 条件，否则报错 duplicate definition。
build tags 和 go test 怎么配合
go test 默认不读取 build tags，所以写了 //go:build windows 的测试文件，在 Linux 上跑 go test 会直接跳过——不是失败，是“看不见”。这容易让你误以为测试覆盖率高，其实压根没跑。
- 想在当前平台运行带 tag 的测试，加
-tags参数：go test -tags=windows - 想验证多平台逻辑是否真能编译通过，用
GOOS=windows go build -o /dev/null .，不生成二进制，只做类型检查 - CI 中建议显式指定
GOOS+-tags组合测试，避免漏掉某平台的编译错误
注意：GOOS=linux go test 不会自动启用 linux tag，必须手动加 -tags=linux，这点和 go build 不同。
常见踩坑：tag 名字拼错、平台常量混淆
build tags 用的是 Go 官方定义的平台标识符，不是操作系统命令输出的字符串。比如：
- macOS 对应
darwin，不是macos或osx - ARM64 架构是
arm64，不是aarch64（Linux 命令里常见这个） -
GOOS和GOARCH是构建时环境变量，而 build tags 是静态标记——别指望在 tag 里写!windows就能自动排除 Windows，它只是编译期开关，不依赖运行时 - 自定义 tag（如
//go:build enterprise）必须在go build -tags=enterprise中显式传入，否则无效
最容易被忽略的是：当多个文件共用同一组 tag 时，如果某个文件漏写了 tag，又恰好和其他文件有同名导出符号，就会触发 “redeclared in this block” 错误——此时不是代码问题，而是 build tag 没对齐。
