Go 构建时怎么指定目标操作系统和架构
Go 原生支持跨平台编译，不需要额外安装头文件或 SDK —— 因为 Go 的标准库是纯 Go 实现的，net、os、syscall 这些包底层已按平台做了抽象封装。真正需要你干预的，只是构建时告诉 go build 目标平台。
常见错误现象：GOOS=linux GOARCH=arm64 go build 在 macOS 上跑出 Linux 二进制，但运行时报 exec format error，其实是没注意交叉编译产物不能直接在宿主机执行（这很正常），不是头文件缺失。
-
GOOS控制目标操作系统（如linux、windows、darwin） -
GOARCH控制 CPU 架构（如amd64、arm64、386） - 组合必须合法：比如
GOOS=windows GOARCH=arm64是支持的，但GOOS=darwin GOARCH=386自 Go 1.17 起已被移除 - 不设环境变量时，默认用当前系统值，
go env GOOS GOARCH可查
调用 C 代码时头文件路径怎么处理
一旦用了 // #include <xxx.h> 或 import "C"，Go 就会触发 cgo，这时才真正涉及头文件。这时候 Go 不再“跨平台透明”，而是依赖宿主机的 C 工具链。
常见错误现象：fatal error: sys/epoll.h: No such file or directory —— 你在 macOS 上写了个只适配 Linux epoll 的 C 片段，却没加构建约束，cgo 尝试编译就失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
// +build linux或//go:build linux约束文件生效范围 - 不要指望
GOOS=linux go build能自动帮你找到 Linux 头文件；它只改 Go 标准库行为，不提供 libc 头文件 - 若需真正跨平台调 C，得自己准备各平台对应的头文件 + 静态库，并用
#cgo CFLAGS和#cgo LDFLAGS指定路径 - cgo 默认开启，禁用它：
CGO_ENABLED=0 go build—— 此时所有import "C"会报错，但能确保纯 Go 构建，避免头文件干扰
syscall 和 unsafe 包里哪些操作是平台敏感的
即使不用 cgo，某些底层操作仍会暴露平台差异。比如 syscall.Syscall 系列函数在不同系统上参数顺序、返回值含义都不同；unsafe.Sizeof 对结构体对齐的影响也随平台变化。
使用场景：写高性能网络代理、自定义 epoll/kqueue/select 封装、内存映射文件等。
-
syscall包已标记为 deprecated，应优先用golang.org/x/sys/unix（Linux/macOS）或golang.org/x/sys/windows（Windows） -
golang.org/x/sys中的常量（如unix.EAGAINvsunix.WSAEWOULDBLOCK）已做平台适配，但你要显式 import 对应子包 - 结构体字段顺序、padding、大小可能因
GOOS不同而异，别用unsafe.Offsetof硬编码偏移量 - 测试这类代码时，务必在目标平台或 Docker 容器中实际跑，光靠构建成功不等于运行正确
为什么本地构建 Windows 程序总提示找不到 kernel32.dll 导入
这不是头文件问题，而是链接阶段找不到 Windows SDK 的导入库（.lib）。Go 的 link 工具不解析 Windows 头文件，但需要对应平台的链接符号表。
常见错误现象：undefined reference to `GetStdHandle' 或构建成功但运行崩溃，提示 DLL 加载失败。
- 在非 Windows 系统（如 macOS/Linux）上交叉编译 Windows 程序，需确保安装了 MinGW-w64 工具链（如
x86_64-w64-mingw32-gcc）并设置CC_FOR_TARGET - Go 1.15+ 默认用内部链接器，若要兼容老 Windows API，可加
-ldflags "-H windowsgui"或-ldflags "-s -w"减小体积 - 更稳妥的做法：用 Windows WSL 或 GitHub Actions 的
windows-latestrunner 构建，避免模拟环境差异 - 如果只是想生成 .exe 文件供他人使用，无需运行时依赖 VC++ 运行库 —— Go 程序默认静态链接，除非你显式用了 cgo 并链接了动态 C 库
跨平台真正的难点不在头文件，而在你是否清楚哪段逻辑依赖了平台特定的系统调用、C 接口或 ABI 行为。一旦写了 import "C" 或直接调 syscall，就要为每个目标平台验证行为一致性，而不是只看能不能编译过去。
