编译标签必须紧贴文件顶部，前面不能有空行、注释或代码；正确写法为//go:build linux（Go 1.17+推荐）或// +build linux（旧式），二者不可混用，且//go:build后须紧跟空行再写package声明。
编译标签怎么写才不会被 Go build 忽略
Go 的编译标签（build tags）不是注释，也不是随便加个 // +build 就生效——它必须紧贴在文件顶部，且前面**不能有空行、不能有其他代码或注释**。常见错误是把标签写在 package 声明之后，或者中间插了一行空行，结果整个文件被 build 系统跳过，还查不出为什么。
正确写法只有两种格式（二者等价，推荐第一种）：
//go:build linux // +build linux
注意：//go:build 是 Go 1.17+ 推荐方式，// +build 是旧式写法；两者**不能混用**在同一文件里；如果用了 //go:build，就必须紧跟一行空行再写 package。
- 标签必须全小写，
linux可以，Linux不行 - 多个平台用空格分隔：
//go:build linux darwin - 排除某个平台用
!windows，但注意逻辑优先级：//go:build linux !cgo表示“Linux 且禁用 cgo”
如何让同一函数名在不同平台返回不同实现
最常用做法是拆成多个同名函数文件，靠编译标签控制哪个参与构建。比如想实现跨平台的临时目录路径获取：
立即学习“go语言免费学习笔记（深入）”；
文件 temp_linux.go：
//go:build linux
package main
func GetTempDir() string {
return "/tmp"
}
文件 temp_windows.go：
//go:build windows
package main
func GetTempDir() string {
return `C:\Temp`
}
关键点：
- 所有文件必须在同一 package 下，函数签名完全一致
- 不能在一个文件里用
runtime.GOOS判断分支——那样会编译进所有平台，只是运行时走不同分支，违背“差异化编译”本意 - 如果某个平台没提供对应文件（比如只写了
linux和windows，但没写darwin），则 macOS 下编译直接报错：undefined: GetTempDir
交叉编译时 build tag 怎么生效
GOOS 和 GOARCH 环境变量决定目标平台，而 build tag 是编译期静态过滤机制——它**不看当前系统，只看你要构建的目标平台**。
例如，在 Linux 上执行：
GOOS=windows GOARCH=amd64 go build -o app.exe .
此时只有 //go:build windows 或 //go:build windows amd64 的文件会被纳入编译，哪怕你是在 Ubuntu 上跑的命令。
- 可以用
go list -f '{{.GoFiles}}' -tags linux查看哪些文件会被 linux 标签选中 - 调试时别依赖
runtime.GOOS打印日志来判断平台——那反映的是构建机，不是目标平台 - 第三方库如果用了 build tag，比如
golang.org/x/sys/unix在 Windows 下默认不参与构建，这是设计使然，不是 bug
常见误用：用 build tag 控制功能开关反而导致链接失败
有人试图用 build tag 区分“是否启用 SQLite”，比如：
//go:build sqlite package main import _ "github.com/mattn/go-sqlite3"
问题在于：这个 import 是空白导入，但实际使用 sql.Open("sqlite3", ...) 的代码可能在另一个没加 tag 的文件里——链接时找不到驱动注册，运行时报 sql: unknown driver "sqlite3"。
真正安全的做法是：
- 驱动导入和使用逻辑放在同一组带相同 tag 的文件里
- 或者用接口抽象，主逻辑只依赖接口，具体实现按 tag 分离
- 避免跨文件隐式依赖——build tag 切割的是文件粒度，不是符号粒度
复杂点在于：build tag 看似简单，但它把编译决策提前到了文件层级，一旦跨文件调用未对齐，就变成静默失效而非报错。
