GOOS/GOARCH环境变量决定构建阶段哪些文件参与编译，go build按其值筛选源文件（如_linux.go仅在GOOS=linux时加载），而非运行时判断；文件名后缀优先级高于//go:build注释，_test.go被go build忽略但go test自动加载，交叉编译须同时显式设置GOOS、GOARCH及CGO_ENABLED=0。
GOOS/GOARCH 环境变量决定哪些文件参与构建
go build 默认按当前主机环境（GOOS 和 GOARCH）筛选源文件，不是“全量编译再运行时判断”，而是构建阶段就剔除不匹配的文件。这意味着 linux_amd64.go 在 macOS 上执行 go build 时根本不会被读取——连语法检查都不会触发。
- 查看当前目标：运行
go env GOOS GOARCH，输出即为实际生效的平台标识 - 显式指定目标：用
GOOS=windows GOARCH=arm64 go build，此时只有_windows_arm64.go、_windows.go、_arm64.go和无后缀文件参与编译 -
_unix.go是无效后缀——Go 不识别unix这个GOOS值，它只认linux、darwin、windows等明确枚举值 - 交叉编译时，
CGO_ENABLED=0会进一步限制可用文件（例如排除含 C 代码的_cgo.go）
文件名后缀优先级高于 //go:build 注释
如果你写了 foo_linux.go，又在文件头加了 //go:build darwin，那这行注释完全无效。构建工具先看后缀，匹配不上就跳过整个文件，注释压根不解析。
- 常见误判场景：想用
//go:build !windows屏蔽 Windows 逻辑，但文件名是net_windows.go→ 它在非 Windows 环境下直接被忽略，根本不会进入构建流程 - 想实现“仅 Linux + 非 ARM64”逻辑？不能靠
_linux.go加//go:build !arm64，得拆成两个文件：net_linux.go（通用 Linux 逻辑）和net_linux_arm64.go（ARM64 特化逻辑），后者会被自动排除 - 多个后缀叠加时，顺序无关：
util_linux_amd64.go和util_amd64_linux.go效果一致，都要求GOOS=linux且GOARCH=amd64
_test.go 是特殊约定，不是条件编译规则
_test.go 文件不会被 go build 包含，但会被 go test 自动加载——这不是由构建约束控制的，而是 Go 工具链的硬编码行为。
- 别指望
myapp_test.go里写个func main()然后go run myapp_test.go能跑起来；go run默认忽略_test.go文件 - 想复用测试逻辑到主程序？把公共代码提成独立包，或改用
_testutil.go这类非_test后缀的命名 -
go list -f '{{.GoFiles}}' ./...可以确认哪些文件被纳入构建列表，比猜更可靠
交叉编译失败常因环境变量未设全
执行 GOOS=linux GOARCH=arm64 go build 却报错“no Go files”，大概率是因为你漏了 CGO_ENABLED=0 —— 当目标平台与当前主机不同时，CGO 默认禁用，但某些依赖仍会尝试调用 cgo，导致构建中断。
立即学习“go语言免费学习笔记（深入）”；
- 安全做法：交叉编译一律显式关闭 CGO：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build - 若必须启用 CGO（如调用系统库），需提前配置对应平台的
CC环境变量，例如CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc - 验证产物平台：用
file your_binary查看 ELF 头信息，确认ELF 64-bit LSB executable, ARM aarch64类字样
