平台专用代码必须按文件粒度拆分并用//go:build约束声明，不可依赖runtime.GOOS运行时判断；编译器不裁剪if分支，未匹配约束的文件（含init、全局变量）被完全忽略，接口需定义在无约束文件中供各平台实现。
Go 多平台构建中，平台专用代码必须按文件粒度拆分，不能靠 if runtime.GOOS == "windows" 这类运行时判断——编译器不识别，链接时会报符号缺失或重复定义。
用构建约束（build tags）隔离平台文件
每个平台专属实现必须放在独立 .go 文件中，并在文件顶部用 //go:build 注释声明生效条件。这是 Go 工具链唯一认可的编译期平台筛选机制。
- 文件名无需带平台后缀（如
os_windows.go），但推荐保持一致便于识别 - 多个约束可组合，例如
//go:build windows && amd64或//go:build darwin || linux - 必须同时写
// +build（旧格式）以兼容部分 CI 工具，虽然 Go 1.17+ 主要用//go:build - 约束不匹配的文件会被
go build完全忽略——包括其中的init()函数和全局变量定义
避免在同一个文件里混写多平台逻辑
常见错误是把 Windows 和 Linux 的路径处理、信号监听、系统调用封装在一个文件里，靠 runtime.GOOS 分支。这会导致：
- 未使用的平台代码仍参与类型检查，容易因缺少类型或函数定义而编译失败
- 交叉编译时无法裁剪无用逻辑，二进制体积增大
- 测试困难：
GOOS=linux go test仍会检查 Windows 分支里的未导出函数调用 - IDE 跳转和补全混乱，因为所有分支都“存在”于同一作用域
共享接口定义要放在非约束文件中
平台差异应通过接口抽象，而接口本身必须定义在无构建约束的文件里（比如 interface.go 或 types.go），否则其他包 import 时会因约束不满足而找不到类型。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 示例：定义
type FileLocker interface { Lock() error; Unlock() error }在lock.go（无约束） - 具体实现分别放在
lock_windows.go（//go:build windows）和lock_unix.go（//go:build darwin || linux） - 调用方只依赖
FileLocker接口，编译时自动绑定对应平台实现 - 切忌把接口和某个平台实现写在同一文件里——那样其他平台 build 就看不到接口了
Windows 上的 syscall 和 golang.org/x/sys/windows 不是跨平台安全的
直接调用 syscall 包里的 Windows API 函数（如 syscall.CreateEvent）会导致 Linux 构建失败，即使加了 runtime.GOOS 判断也无效——因为符号解析发生在编译阶段。
- 必须把这类调用完全封装进带
//go:build windows约束的文件 - 优先使用
golang.org/x/sys/windows而非原生syscall，前者有更稳定的 ABI 和文档 - 若需模拟 Unix 信号行为（如
SIGINT），不要在 Windows 文件里硬写syscall.SIGINT——它在 Windows 上未定义；改用os.Interrupt - 注意
x/sys/windows中某些函数返回error类型是uintptr，需显式转成error（如errnoErr(errno)）
最易被忽略的一点：构建约束不是注释，它影响整个文件的可见性。哪怕只有一行 import "golang.org/x/sys/windows"，没加 //go:build windows，这个文件在 macOS 上就根本编译不过——不是运行时报错，是压根不会被加载。
