go build 依据文件名后缀（如_linux.go）和构建标签（//go:build）筛选源文件，后缀优先级高于标签；goos环境变量仅影响目标平台标准库链接，不决定文件是否参与编译。
go build 时到底选了哪些文件
Go 不是靠 runtime.GOOS 做编译分支，而是靠文件是否被纳入编译集合来决定逻辑归属。关键判断依据只有两个：go build 当前看到的源文件列表，以及每个文件顶部的构建约束或后缀名。
常见错误现象：写了 //go:build windows，但 go build 在 Linux 下仍报错说找不到某个 Windows API 函数——说明该文件实际被编译进去了，不是没生效，而是你漏掉了 package 前的空行，或写了多余注释导致构建标签失效。
- 构建标签必须紧贴
package声明前，中间最多一个空行；写在函数里、文档后、或带缩进的注释行里都无效 - 文件名后缀（如
_linux.go）优先级高于构建标签；若同时存在net_linux.go和net.go，后者会被所有平台编译，容易引发符号重复定义 -
go list -f '{{.GoFiles}}' .可直接查看当前构建会加载哪些.go文件，比猜更可靠
GOOS=linux go build 为什么没加载 _linux.go
交叉编译本身不改变构建标签匹配逻辑，GOOS 环境变量只影响目标平台输出格式和标准库链接行为，不影响源文件筛选。真正决定 _linux.go 是否参与编译的，是当前 host 的 runtime.GOOS 值——也就是你执行 go build 的机器操作系统。
也就是说：GOOS=linux go build 在 macOS 上运行时，net_linux.go 不会被加载，因为 Go 编译器此时读取的是 host 的 darwin，不是你设的 linux。
- 要让
_linux.go在非 Linux 环境下也参与编译，必须用显式-tags：比如go build -tags linux -
//go:build linux同理，它匹配的是构建环境 OS，不是目标 OS；想强制启用，一样得加-tags linux - 交叉编译真正起作用的场景是：你本地是 Linux，但想生成 Windows 二进制——这时
_windows.go才会被自然选中
如何安全地混用构建标签与平台后缀
Go 官方不推荐在同一项目中混用两种机制，因为行为未定义。尤其当一个文件既有 _linux.go 后缀，又写了 //go:build darwin，Go 工具链可能忽略标签、或报错、或静默跳过——不同版本表现不一致。
生产环境建议只选一种，并统一落地：
- 简单项目用后缀：如
fs_unix.go/fs_windows.go，清晰、无需额外参数、IDE 支持好 - 复杂组合（如
linux && arm64 && cgo）必须用//go:build，且记得兼容旧版写法：//go:build linux && arm64 && cgo+// +build linux,arm64,cgo - 自定义标签（如
enterprise）只能通过-tags激活，无法用后缀模拟
条件编译和 runtime.GOOS 的分工边界
很多人误以为 runtime.GOOS == "linux" 是条件编译的替代方案，其实它是运行时兜底手段，适用场景非常有限。
典型误用：用 if 分支包裹大段平台专属逻辑（比如完整实现一套 Windows 服务管理器），结果所有平台二进制都包含两套代码，体积膨胀、潜在符号冲突、CI 测试覆盖不到。
-
runtime.GOOS只适合微小差异：路径分隔符、默认配置项、日志前缀等不影响二进制结构的字段 - 涉及系统调用、cgo 依赖、API 差异大的模块，必须走文件级条件编译，否则无法通过构建校验
- CI 脚本中若只跑
go build默认命令，等于只验证了 host 平台逻辑；多平台交付必须显式跑GOOS=windows go build和GOOS=linux go build两类命令
go build。把“目标平台”和“构建平台”搞混，是绝大多数条件编译失效的根源。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
