runtime.GOOS分支会导致编译失败，因为Go是静态编译语言，编译器不跳过if内未执行代码，只要引用了windows包等平台专属符号，Linux下build就会报undefined: windows错误；正确做法是用文件名后缀（如_windows.go）或//go:build标签做编译期隔离。
不能在单个文件里用 runtime.GOOS 分支调用平台专属 API，否则 Linux 下 go build 会直接报 undefined: windows 错误——Go 是静态编译语言，所有被引用的符号都必须可解析，哪怕它藏在 if 里。
为什么 runtime.GOOS == "windows" 分支会导致编译失败
Go 编译器不跳过未执行的代码分支，只检查语法和符号可达性。只要函数体里写了 windows.GetVersion()，哪怕外面套了 if runtime.GOOS == "windows"，Linux 环境下 go build 就会失败，因为 windows 包根本无法导入，GetVersion 符号不可解析。
更麻烦的是，golang.org/x/sys/windows 这类包在非 Windows 环境下连 go mod tidy 都会出错，不是运行时问题，是编译期硬拦截。
- 错误现象：
undefined: windows、import "golang.org/x/sys/windows": import not found - 根本原因：Go 没有预处理器，
if不是编译期裁剪机制 - 后果：CI 流水线在 Linux 机器上构建 Windows 版本失败，或本地开发环境无法同时维护多平台逻辑
_linux.go、_darwin.go、_windows.go 文件命名是最稳的隔离方式
把平台相关实现拆成独立文件，用下划线加 OS 名后缀，Go 工具链会在编译时自动决定是否包含该文件——不需要任何构建参数，也不依赖 GOOS 环境变量值，CI 中零配置即可工作。
立即学习“go语言免费学习笔记（深入）”；
所有文件必须同包、函数签名完全一致（比如都实现 func GetCPUUsage() (float64, error)），调用方无感知。
-
cpu_linux.go：读取/proc/stat，用syscall或golang.org/x/sys/unix -
cpu_windows.go：调用pdh.dll，导入golang.org/x/sys/windows -
cpu_darwin.go：用host_statistics系统调用，依赖C.mach_host_self() -
_unix.go可用于共性逻辑（如信号处理、socket 选项设置），匹配linux、darwin、freebsd
//go:build 约束要写对位置和语法，否则整个标签失效
//go:build 注释必须紧贴文件顶部第一行，前面不能有任何空行、文档注释或空格；后面必须跟一个空行；逻辑运算符只能用 ||、&&、!，不能写 or 或 AND。
常见错误写法：//go:build linux 上面有空行、或后面没空行、或混用 // +build 旧格式，都会导致该文件变成“全平台生效”，失去隔离意义。
- ✅ 正确：
//go:build linux || darwin // +build linux darwin <p>package monitor
- ❌ 错误：
/* * cpu.go */ //go:build windows package monitor
（顶部有注释，//go:build失效） -
GOOS=windows go build不会自动启用windows标签，但//go:build windows会被识别；自定义标签（如experimental）必须显式加-tags=experimental
测试时 -tags 参数不可省略，否则平台专属逻辑压根不会跑
go test 默认完全忽略构建标签，哪怕你写了 //go:build windows 的测试文件，在 Linux 上执行 go test 也不会报错，而是直接跳过——你以为测全了，其实那段逻辑一次都没执行。
验证 Windows 实现是否正确，必须运行：go test -tags=windows；验证能否在目标平台编译通过（不生成二进制），用：GOOS=windows go build -o /dev/null .
- 容易被忽略的点：CI 中只跑
go test，没加-tags，导致平台专属逻辑长期处于未测试状态 - 更隐蔽的问题：某些函数签名看似一致，但返回值类型在不同平台下用了不同包的类型（比如
unix.Stat_tvswindows.Win32FindData），接口抽象时必须统一为自定义结构体，不能直接暴露底层类型
