Makefile 里直接 go mod tidy 会破坏构建可重现性
Go 的 go mod tidy 默认修改 go.sum 和 go.mod，如果在 make build 前自动执行，CI 构建可能因网络抖动拉到不同版本的间接依赖，导致本地能跑、CI 报错。
- 只在显式更新依赖时运行：
make deps而非make build -
deps目标里加GO111MODULE=on go mod tidy -v，并检查退出码，失败立即中断 - CI 流水线中，
go build前必须加go mod verify，确保go.sum未被绕过或篡改
跨平台编译时 GOPATH 和 GOOS/GOARCH 不能靠环境变量硬编码
Makefile 里写死 GOOS=linux GOARCH=amd64 go build 看似省事，但开发者在 macOS 上执行时，GOOS 会被 shell 环境继承，实际编译出 macOS 二进制，和预期不符。
- 所有构建目标显式覆盖：用
env GOOS=linux GOARCH=arm64 go build -o bin/app-arm64 ./cmd/app - 避免
export GOOS=...—— Makefile 的 export 不跨 target 生效，反而容易干扰后续命令 - 若需复用，定义变量如
LINUX_AMD64 = env GOOS=linux GOARCH=amd64，再在 recipe 中调用$(LINUX_AMD64) go build ...
vendor 目录不是“开关”，启用后必须全局一致
有些团队加了 go mod vendor 就以为能离线构建，结果发现 go test 仍连外网 —— 因为 go test 默认不读 vendor，除非加 -mod=vendor。
- 所有 Go 命令（
build/test/run）都得显式传-mod=vendor - Makefile 里统一定义
GOFLAGS := -mod=vendor，比每个命令重复写更可靠 - 注意：开启 vendor 后，
go mod graph等诊断命令会失效，调试依赖问题时得临时关掉
Makefile 无法自动感知 go.mod 变更，增量构建要靠时间戳硬判断
Make 默认只看文件修改时间，而 go.mod 更新后，go build 并不依赖它 —— 所以改了依赖，make build 还是走缓存，二进制没更新。
立即学习“go语言免费学习笔记（深入）”；
- 把
go.mod和go.sum加进构建目标的 prerequisites：bin/app: $(shell find . -name 'go.mod' -o -name 'go.sum') - 慎用
$(wildcard)—— 如果项目有多个go.mod（如子模块），它只会匹配当前目录，漏掉嵌套路径 - 更稳的方式：用
find . -name 'go.mod' -print0 | xargs -0 stat -c '%y %n' | head -1生成唯一指纹，作为触发条件
真正麻烦的不是写对 Makefile，而是当 go.work 开始普及、多模块协同开发变多时，make 对 workspace 没原生支持 —— 那时候就得在 Makefile 里手动解析 go.work 列表，再挨个 cd 执行，容易出错。
