Go build 优先按文件名后缀（如\_linux.go）裁剪代码，而非内容或runtime.GOOS；\_unix.go无效，//go:build在多条件时更灵活，CGO_ENABLED=0对交叉编译至关重要。
为什么 go build 有时完全忽略你的平台专属文件？
因为 Go 工具链优先按文件名后缀做编译裁剪，而不是读代码内容——_linux.go 只在 GOOS=linux 时被加载，其他平台下它根本不会进入编译流程，连语法检查都不会触发。
-
_unix.go是无效后缀：Go 不识别unix作为合法GOOS值，该文件会被静默跳过（不报错、不警告） - 文件名后缀比
//go:build注释优先级更高：哪怕你写了//go:build !windows，只要文件叫net_windows.go，它就只在 Windows 下参与构建 - 同一包里不能同时存在
main.go和main_linux.go：前者会被所有平台编译，后者只在 Linux 下编译，导致重复定义main函数 - 验证实际参与构建的文件：运行
go list -f '{{.Name}} {{.GoFiles}}' ./，输出中只列出当前GOOS/GOARCH下真正被选中的.go文件
GOOS 和 GOARCH 怎么影响交叉编译结果？
它们不是运行时变量，而是构建期硬编码进二进制的元信息。一旦设定了 GOOS=windows GOARCH=amd64，生成的可执行文件就只能在 Windows x86_64 上运行，且无法通过改环境变量绕过。
- 必须显式设置：默认值是当前宿主机平台，不设就不会交叉编译
-
CGO_ENABLED=0是关键开关：启用 CGO 时，交叉编译会尝试调用目标平台的 C 头文件和链接器，宿主机通常不具备这些，直接失败 - Windows 输出要加
.exe后缀：Linux/macOS 下不需要，但go build -o app.exe在非 Windows 下也能生成带.exe后缀的文件（只是无法双击运行） - ARM 架构需额外参数：比如
GOARCH=arm还得配GOARM=7；GOARCH=arm64则不需要GOARM
什么时候该用 //go:build 而不是文件后缀？
当逻辑分支不严格绑定单一操作系统，而是需要组合条件（如 “Linux 或 FreeBSD”）、排除平台（如 “非 Windows”），或涉及自定义标签（如 production）时，必须用构建约束，不能依赖后缀。
- 后缀只支持精确匹配：
_linux.go≠_unix.go，后者无效；想覆盖多个类 Unix 系统，得写//go:build linux || darwin || freebsd - 多标签组合更灵活：
//go:build cgo && linux可用于仅在启用 CGO 的 Linux 下生效的代码 - 兼容旧工具链：建议同时写两行：
//go:build linux和// +build linux，避免 Go 1.15 及更早版本解析失败 - 标签必须紧贴
package声明前，中间最多一个空行；写在函数里或注释块中间会被忽略
别把 runtime.GOOS 当条件编译用
它只是运行时读取的字符串变量，编译器不会据此剔除代码。所有分支都会被打包进最终二进制，哪怕你只在 if runtime.GOOS == "windows" 里写了三行代码。
立即学习“go语言免费学习笔记（深入）”；
- 体积膨胀：不同平台的实现逻辑全打进一个二进制，浪费空间
- 符号冲突风险：比如 Windows 专用的
syscall类型在 Linux 下不存在，但若用runtime.GOOS分支，编译仍会检查整块代码，可能报错 - 适合场景极少：仅限路径分隔符（
filepath.Separator）、日志格式微调等极轻量差异 - 真要跨平台适配，必须用构建约束或文件后缀，在编译期就分离代码
runtime.GOOS 从不参与构建裁剪——它只是个普通变量，别给它赋予编译期语义。 
