Go通过//go:build标签或_GOOS.go文件后缀实现编译期裁剪，二者任一匹配即参与编译；标签需紧贴package前、独立成行，支持布尔表达式；文件后缀按_goos_goarch顺序自动匹配平台；不支持单函数级条件编译。
Go 没有 #ifdef，但能真正做编译期裁剪——不是靠运行时判断，而是让不匹配的文件压根不进编译流程。关键在构建标签（//go:build）和文件命名约定，二者选一即可，但推荐用 //go:build。
用 //go:build 标签控制文件参与编译
这是 Go 1.17+ 官方推荐写法，替代旧式 // +build 注释（仍兼容，但新项目别用）。标签必须紧贴 package 声明前，中间最多一个空行。
- 语法是布尔表达式：
//go:build linux || (darwin && arm64)表示“Linux 或 macOS+ARM64” - 否定用
!：//go:build !windows排除 Windows - 多个条件用逗号表示“且”：
//go:build linux,amd64要求同时满足 - 标签必须独立成行，不能和其他注释混写；否则整个标签失效
- 如果文件里写了
//go:build，就不能再写// +build，否则报错build constraints ignored
用 _GOOS.go 文件后缀自动匹配平台
Go 编译器会自动识别形如 config_linux.go、network_windows.go、util_darwin_arm64.go 的文件名，并只在对应 GOOS/GOARCH 下加载它们。无需额外注释。
- 后缀顺序固定：先
_GOOS，再_GOARCH，例如io_linux_amd64.go - 支持的
GOOS值包括：linux、windows、darwin、freebsd、openbsd等（大小写敏感，全小写） - 同一包内多个同名函数（如
OpenLog()）可分别定义在不同后缀文件中，编译时只取一个，不会冲突 - 注意：这种机制是隐式的，调试时容易漏看哪个文件被实际编译了——建议配合
go list -f '{{.GoFiles}}'验证
交叉编译时如何确保条件编译生效
GOOS 和 GOARCH 环境变量不仅影响二进制目标平台，也直接驱动构建标签和文件后缀匹配逻辑。但要注意：它们只在 go build 运行时起作用，不影响 go run（后者总用当前平台）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 . - 错误写法：
go run .—— 即使设置了GOOS，也不会触发跨平台条件编译 - 若同时用了构建标签和文件后缀，二者是“或”关系：任一匹配即参与编译；建议只选一种，避免行为不可控
- CI/CD 中务必显式设置
GOOS/GOARCH，不要依赖宿主机环境；Docker 构建时尤其注意基础镜像是否预设了这些变量
为什么 runtime.GOOS 不适合替代条件编译
虽然你能在代码里写 if runtime.GOOS == "windows" { ... }，但这属于运行时分支，不是条件编译：
- 所有分支代码都会打进二进制，哪怕只跑在 Linux 上，Windows 相关逻辑也占体积、可能引入未链接的符号（比如调用
syscall.NewLazySystemDLL） - 无法规避平台专属依赖：比如 Windows 文件里 import
"golang.org/x/sys/windows"，Linux 下go build会直接失败，根本到不了运行时 - 测试困难：想单独测 Windows 分支，就得在 Windows 环境跑，没法靠构建标签隔离
- 真正需要运行时判断的场景极少，通常是启动后动态适配（如检测桌面环境），而非功能主干逻辑
最易被忽略的一点：构建标签和文件后缀都作用于**整个源文件**，无法对单个函数或代码块做条件编译。如果一个文件里混着多平台逻辑，要么拆分，要么用 build tags 整体屏蔽——没有折中方案。
