Makefile 的 build 目标应先切到项目根目录再构建：cd $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST)))) && go build -o ./bin/app ./cmd/app，避免因路径不匹配导致 cannot find module 错误。
Makefile 里 build 目标怎么写才不踩 Go 模块路径坑
Go 编译依赖 go.mod 中的模块路径，而 Makefile 本身不解析它。直接写 go build -o bin/app . 看似能跑，但一旦项目被别人 git clone 到非 GOPATH 或非模块路径下（比如 /tmp/myproj），go build 就可能报 cannot find module providing package。
根本原因是：Go 要求当前目录或父目录存在合法 go.mod，且模块路径（module github.com/user/repo）必须与实际路径匹配——而 Makefile 不会帮你校验这个。
- 始终在
build命令前加cd $(shell dirname $(realpath $(firstword $(MAKEFILE_LIST)))) &&，确保工作目录是项目根（即含go.mod的目录） - 显式指定输出路径，避免污染源码目录：
go build -o ./bin/app ./cmd/app（推荐用./cmd/app而非.，防止误编译测试文件） - 别硬编码
GOOS/GOARCH，除非真要交叉编译；默认留给本地环境更安全
test 目标为什么总漏跑子目录，怎么改
Go 默认 go test 只跑当前目录下的 *_test.go，不会递归进 internal/ 或 pkg/。写成 go test ./... 看起来全量，但实际会跳过 vendor 和以 _ 或 . 开头的目录——这没问题；真正容易漏的是被 //go:build ignore 或 // +build ignore 标记的测试文件，还有那些没放在标准包结构里的临时测试目录（比如 tests/e2e/）。
- 用
go test -v ./... 2>/dev/null | grep '^ok' | wc -l粗略看跑了多少包，比单纯看输出更可靠 - 如果真要包含非标准路径，得显式列出：
go test -v ./... ./tests/e2e/... - CI 环境务必加
-race和-count=1（防缓存），本地开发可省略-race省时间
Makefile 里要不要写 clean？怎么清才干净
Go 编译产物只有二进制和 ./bin 下的文件，但很多人忘了 go test 会生成 coverage.out、test.out，还有 go build -a（强制重编）触发的 $GOROOT/pkg 缓存——这些不该由 make clean 碰。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只清理项目内生成物：
rm -f ./bin/* ./coverage.out ./test.out - 别碰
$(go env GOCACHE)或$(go env GOPATH)/pkg，那是 Go 自己管的，清了反而拖慢后续构建 - 如果用了
cgo，记得加rm -f *.o *.a（仅限 C 文件同目录时）
跨平台构建时 GOOS 和 GOARCH 怎么传进命令
直接在 Makefile 里写死 GOOS=linux GOARCH=amd64 go build 是错的——Make 会把 GOOS=linux 当作变量赋值，但后面的 go build 并不在同一 shell 上下文里生效。必须用 env 或前置导出。
- 正确写法：
env GOOS=linux GOARCH=arm64 go build -o ./bin/app-linux-arm64 ./cmd/app - 或者用 Make 变量透传：
build-linux-arm64: GOOS := linux+build-linux-arm64: GOARCH := arm64，再在命令里用$(GOOS)引用 - 注意：
CGO_ENABLED=0必须和GOOS同行，否则静态链接失效；Windows 下还要额外处理路径分隔符（./bin/app.exe）
最麻烦的其实是交叉编译时的依赖：比如用了 net/http，GOOS=js 就根本不支持；这类问题不会报错，而是运行时 panic，得靠目标平台的真实测试兜底。
