交叉编译时必须显式设置CGO_ENABLED=0，否则因缺失目标平台C工具链导致链接失败；若依赖net、os/user等包则隐含cgo，不关闭将报cross compilation not supported错误。
交叉编译时 CGO_ENABLED=0 必须显式设置
只要代码里用了 net、os/user、os/signal 等依赖系统调用的包，背后就隐含 cgo；不关掉它，Linux/macOS/Windows 交叉编译会直接失败，报错 cross compilation not supported。
这不是警告，是硬性限制——Go 默认启用 cgo，但交叉编译时没有对应平台的 C 工具链，链接阶段必然崩。常见误操作是只设 GOOS 和 GOARCH，漏掉 CGO_ENABLED=0。
-
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp-arm64是安全底线 - 若必须保留 cgo（如调用 OpenSSL 或 SQLite），就得配对应平台的交叉编译工具链（例如
x86_64-linux-gnu-gcc），不是加个环境变量就能跑通 -
CGO_ENABLED=0下，net包会回退到纯 Go 实现（如 DNS 查询走 UDP 而非系统 resolv.conf），行为略有差异，需在目标环境验证
构建标签（build tags）和文件名后缀要配合用
光靠 // +build linux 容易出错：空行漏了、空格写成下划线、标签没顶格写，Go 就当它是普通注释，所有平台都编译该文件，结果 Windows 上跑 Linux 专用代码直接 panic。
更稳的做法是「标签 + 文件名」双保险：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 写
fs_linux.go和fs_windows.go，文件名自带平台语义，Go 自动识别，不用手写标签 - 真要用标签，必须满足：前面有且仅有一个空行、
// +build后跟空格、多条件用空格分隔（// +build linux darwin表示“Linux 或 Darwin”，不是“且”） - 带 cgo 的文件（如
inotify_linux.go）必须配一个inotify_stub.go，用// +build !linux隔离，否则非 Linux 平台编译失败
go build -ldflags 注入版本时要注意变量作用域
-ldflags "-X main.version=v1.2.3" 看似简单，但变量必须声明在 main 包里，且类型只能是 string。写成 var Version = "v1.2.3" 或放在其他包里，注入就失效，运行时还是空字符串。
生产构建不注入版本信息，等于放弃溯源能力——同一 commit 编出来的二进制 hash 相同，但你根本不知道它打在哪天、哪个分支、有没有加 patch。
- 在
main.go顶部声明：var version string，然后用-X main.version=$(git describe --tags) - 时间戳建议用 UTC：
-X main.date=$(date -u +%Y-%m-%dT%H:%M:%SZ) - 别忘了同时加
-s -w剥离调试符号，否则体积大、路径暴露、逆向风险高
vendor 目录不是必须，但上线前必须验证一致性
go mod vendor 生成的目录只是快照，不代表实际构建时用的就是这些代码。如果 go.sum 里记录的校验和与 vendor 中文件不一致，go build 仍会去拉远程模块，导致构建产物不可重现。
CI/CD 流程里最容易被跳过的一步就是校验 vendor 是否干净。
- 上线前跑一次：
go mod vendor && git status --ignored，确认 vendor 下没未提交变更 - 构建命令里加上
-mod=vendor，强制只读 vendor 目录，避免网络波动或模块源失效影响发布 - 别把
vendor/提交到主干又长期不更新，旧依赖里的 CVE 可能悄悄潜伏半年
