编译标签不是注释，它决定源文件是否参与构建——写错位置、格式不合规，整个标签就失效，Go 会照常编译不该出现的代码，轻则报符号未定义，重则直接构建失败。
// +build 标签必须紧贴文件顶部且带空行
构建标签被忽略的最常见原因：没在正确位置，或格式不对。它必须是文件最开头的注释块（可含多个 // +build 行），且与 package 声明之间**严格保留一个空行**。
-
// +build linux前面不能有任何内容（包括空行、其他注释、BOM 字符） -
// +build linux和package main之间必须有且仅有一个空行；少或多都会让标签失效 - 写成
//+build linux（中间无空格）或// +buildlinux（后面紧贴）同样无效 - 标签行内用逗号分隔表示“与”，用空格分隔表示“或”：
// +build linux,amd64只编译 Linux+AMD64；// +build windows darwin编译 Windows 或 macOS
文件后缀比 // +build 更直观且不易出错
对纯平台差异逻辑，优先用文件名后缀（如 net_linux.go、net_windows.go），Go 编译器会自动识别并仅加载匹配当前 GOOS 的文件，无需手写标签，也规避了格式错误风险。
- 后缀规则只认
_linux、_darwin、_windows、_386、_arm64等标准值，自定义后缀（如_prod）无效 - 若同时存在
net_unix.go和net_linux.go，而当前GOOS=linux，两者都会被加载——需确保逻辑不冲突 - 当需要组合条件（如
linux + cgo）时，仍需回退到// +build，因为后缀不支持逻辑运算
运行时判断 runtime.GOOS 不能替代编译标签
runtime.GOOS 是字符串常量，适合做路径拼接、信号处理等轻量分支，但它无法解决编译期符号缺失问题——比如 Windows 文件里调用了 unix.Syscall，即使加了 if runtime.GOOS == "linux"，Go 编译器仍会尝试解析该符号并报错。
- 仅当所有平台都能合法解析该文件全部代码时，才可用
runtime.GOOS分支 - 涉及系统调用、cgo、平台专属类型（如
windows.Handle）的代码，必须用构建标签物理隔离 -
runtime.GOOS值在编译时已固化，不是运行时查环境变量，所以无性能损耗，但测试覆盖需多平台执行
cgo 与交叉编译的隐性约束
cgo 开启状态和目标平台共同影响构建行为，尤其在交叉编译时容易踩坑：本地是 macOS，却想构建 Linux 二进制，若某文件含 // +build cgo 且依赖 C 头文件，CGO_ENABLED=0 go build -o app-linux -ldflags="-s" -v 会跳过它；但若漏掉 CGO_ENABLED=0，又可能因找不到 Linux 头文件而失败。
立即学习“go语言免费学习笔记（深入）”；
-
// +build cgo不等于 “启用 cgo”，而是“仅当 CGO_ENABLED=1 时才参与编译” - 交叉编译时，
CGO_ENABLED=0是默认行为；若需启用，必须显式设为1并提供对应平台的CC工具链 - 含 cgo 的文件若未加
// +build cgo，会在CGO_ENABLED=0时被静默忽略——但这不是安全做法，应显式标注 - 自定义标签（如
// +build debug）需配合go build -tags debug才生效，且与平台标签共存时遵循逻辑组合规则
真正难的不是写对一行 // +build，而是判断某个逻辑到底该放编译期还是运行时——一旦把平台专属符号塞进运行时分支，编译就崩，而且错误信息往往指向无关行号。
