标准Go项目Makefile需正确指定包路径、变量命名、交叉编译、依赖管理及版本注入：如go build -o bin/myapp ./cmd/myapp，BIN_NAME变量统一命名，OSARCHS动态生成target，CGO_ENABLED=0，LDFLAGS注入VERSION并去调试信息，verify-mod校验go.mod/go.sum。
直接用 make build 就能跑通标准 Go 项目构建流程，但前提是 Makefile 写对了——否则不是报 no Go files in，就是版本没注入、跨平台输出名混乱、CI 构建缓存失效。
为什么 go build 不能直接塞进 Makefile 里写死路径
Go 的 go build 默认只扫描当前目录，而绝大多数规范 Go 项目主程序在 cmd/myapp/main.go。如果 Makefile 在根目录，写成 go build -o bin/app . 必然失败。
- 必须显式指定包路径：
go build -o bin/myapp ./cmd/myapp - 别用
cd cmd/myapp && go build：shell 切换目录不可靠，多 target 并发执行时会污染环境 - 二进制名建议变量化：
BIN_NAME ?= myapp，后续统一用$(BIN_NAME)，避免硬编码散落各处 - Windows 下本地生成不加后缀也能运行，但 CI 流水线里务必用
GOOS=windows make build触发交叉编译逻辑，否则本地和远程行为不一致
deps 和 clean 必须拆开，且 clean 要清三处
deps 和 clean 是独立生命周期的 target，不能合并进 build；否则每次构建都强制 tidy + download，既破坏 CI 缓存，又让 PR diff 里混入无关的 go.sum 变更。
-
deps:应只做两件事：go mod tidy+go mod download - 所有构建类 target（
build、test、lint）都声明deps为前置依赖：build: deps -
clean必须覆盖三类内容：rm -rf bin/、go clean -cache、go clean -modcache——缺一不可，否则下次构建可能复用脏缓存或旧 module 版本
交叉编译多平台不能手写六七条 GOOS/GOARCH
手动写 GOOS=linux GOARCH=amd64 go build 容易漏平台、难维护、输出名难统一。更糟的是，硬拼接 $(BIN_NAME)-$(GOOS)-$(GOARCH) 在 Makefile 中常因变量提前展开出错。
- 定义平台列表：
OSARCHS = linux/amd64 linux/arm64 darwin/amd64 windows/amd64 - 用
$(foreach osarch,$(OSARCHS),$(eval $(call build-target,$(osarch))))动态注册每个 target - target 名用下划线分隔：
build-linux_amd64，这样make build-%可通配调用 - 输出路径中必须含平台标识：
go build -o bin/$(BIN_NAME)-$(subst /,_,$(osarch)) ./cmd/$(BIN_NAME) - 务必设
CGO_ENABLED ?= 0，尤其生产环境，避免动态链接导致部署失败
版本注入和 verify-mod 是最容易被跳过的环节
没注入 Git commit 或 tag 的二进制等于“黑盒”，线上出问题根本没法回溯；而没检查 go.mod/go.sum 是否已提交，会导致本地能过、CI 报错、同事拉代码直接构建失败。
- 版本建议从 Git 获取：
VERSION ?= $(shell git describe --tags --always --dirty 2>/dev/null || echo "v0.0.0-dev") - LDFLAGS 注入要带
-s -w去调试信息：LDFLAGS := -ldflags="-X main.version=$(VERSION) -s -w" -
verify-mod:必须检查是否遗漏提交：git status --porcelain go.mod go.sum | grep -q '^??' || (echo "go.mod or go.sum modified"; exit 1)
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
