Go项目交叉编译失败、测试静默失败、Windows下Makefile执行异常，根源在于环境变量、工具链路径与执行上下文未对齐：go run不支持交叉编译，必须用GOOS/GOARCH前置的go build；CGO_ENABLED=0需显式设置；Windows需适配命令（如del替代rm）或改用Taskfile跨平台。
直接用 go build 跑不起来的交叉编译、测试失败却没报错、Makefile 在 Windows 上执行不了——这些问题不是 Go 本身的问题，而是构建环境没对齐。核心在于：环境变量、工具链路径、执行上下文三者必须一致。
GOOS/GOARCH 交叉编译总生成当前平台二进制？
根本原因不是命令写错了，而是 go run 不支持交叉编译，且环境变量未在子 shell 中生效。
-
go run main.go永远只编译运行当前平台，它不读GOOS/GOARCH - 必须用
go build，且变量要前置：例如GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 . - 如果用了
make，确保 Makefile 中每条命令都显式带变量，别依赖export（Make 的每个命令默认是新 shell） - 含 cgo 的项目要禁用：加
CGO_ENABLED=0，否则跨平台时会卡在找不到对应平台的 C 工具链
Makefile 在 Windows 上执行失败或命令不识别？
Make 默认依赖 Unix shell 工具（rm、sh），Windows 原生 cmd 或 PowerShell 不兼容。
- 不要写
rm -rf ./bin，改用del /q bin\* 2>nul || echo.（Windows）或保留rm但要求用户装 Git for Windows 或 WSL - 更稳妥的做法是换用
Taskfile：YAML 格式、跨平台、原生支持条件判断和并行；CLItask在 Windows/macOS/Linux 行为完全一致 - 若坚持用 Make，把平台检测逻辑写进 Makefile：
ifeq ($(OS),Windows_NT) … else … endif，但维护成本高
自动化构建中 os/exec 命令莫名卡死或错误被吞？
这是最隐蔽也最常踩的坑：子进程 stdout/stderr 缓冲区满后挂起，而 Go 主程序没读就一直等。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 永远显式设置
cmd.Stdout和cmd.Stderr，哪怕指向io.Discard - 别只用
cmd.Run()，超时控制必须用exec.CommandContext(ctx, ...)配合context.WithTimeout -
err不为空 ≠ 命令失败：需用errors.Is(err, exec.ErrExit)判断是否是退出码非零导致，否则可能把 I/O 错误误判为业务失败 - 避免拼接字符串执行命令：
exec.Command("sh", "-c", "rsync "+src+" "+dst)有注入风险；改用exec.Command("rsync", "-avz", src, dst)
CI 中多平台构建产物上传失败或路径错乱？
GitHub Actions 或 GitLab CI 默认工作目录不稳定，./bin 可能不存在，或权限不足。
- 构建前先创建输出目录：
mkdir -p ./bin，别假设路径已存在 - 交叉编译产物名必须带平台标识，如
app-linux-amd64，否则后续上传步骤容易覆盖 - 上传动作（如
actions/upload-artifact）要指定path为绝对路径或相对于工作目录的明确路径，避免 glob 匹配到临时文件 - Linux runner 默认无 root 权限，
chmod +x产物时用sudo要谨慎；更安全的是构建时加-ldflags '-s -w'减小体积并去掉调试信息
真正麻烦的不是写多少行构建脚本，而是每次换环境都要重新验证路径、权限、shell 行为、变量作用域——这些细节不会报错，只会让构建产物“看起来成功，实际不能用”。
