Makefile不是Golang必需品，但能固化环境搭建、构建、测试等重复流程，实现可复用、可传递、可CI集成；它不替代go命令，而是串联并约束其执行上下文、路径、参数与依赖管理。
Makefile 不是 Golang 的必需品，但它是把环境搭建、构建、测试这些重复动作“固化下来”的最轻量可靠方案。它不替代 go 命令，而是把它们串成可复用、可传递、可 CI 集成的流程。
make init 为什么比手动 go mod init 更稳
新手常在错误目录下执行 go mod init，导致模块路径错、后续 go get 失败或依赖解析异常。Makefile 可强制锁定操作上下文：
- 用
$(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))精确获取 Makefile 所在目录，所有命令都从此处出发 -
init目标先检查go.mod是否已存在，避免重复初始化报错 - 自动执行
go mod tidy，而非仅go mod init—— 后者不拉依赖，tidy才补全且校验兼容性 - 支持传参：
make init MODULE_NAME=github.com/user/project，避免手输拼错
交叉编译时 bin/app 被覆盖的根源和解法
写 GOOS=linux go build -o bin/app . 再写 GOOS=darwin go build -o bin/app .，结果只有最后一个生效——这不是 Makefile 的 bug，是输出路径没做区分。
- 必须把平台信息嵌入输出名：
-o bin/app-$(GOOS)-$(GOARCH) - Windows 需显式加后缀：
-o bin/app-windows-amd64.exe，Makefile 不会自动补.exe - 定义默认变量：
GOOS ?= linux、GOARCH ?= amd64，方便局部覆盖又不失兜底 - 若项目含 cgo，交叉编译前加
CGO_ENABLED=0，否则大概率报exec: "gcc": not found
go install gopls/dlv 总失败？关键在上下文隔离
go install golang.org/x/tools/gopls@latest 在项目根目录下运行，容易因当前目录有 go.mod 触发模块构建逻辑，而不是全局安装工具。
立即学习“go语言免费学习笔记（深入）”；
- 所有
go install前加cd /tmp &&，彻底脱离项目上下文 - 必须带
@latest或具体版本，如@v0.15.2；省略则报no required module provides package - 设
GO111MODULE=on环境变量，确保模块感知开启，避免 fallback 到 GOPATH 模式 - Delve 必须从源码装：
go install github.com/go-delve/delve/cmd/dlv@latest，二进制包不适用
build 报 cannot find module？别怪 Makefile，查三件事
这个错误和 Makefile 写得对不对无关，纯粹是 Go 模块系统找不到匹配的物理路径。
- 确认当前 shell 工作目录是否等于
go.mod所在目录（不是子目录） - 检查
go.mod里声明的模块名（如module github.com/user/repo）是否与实际 Git 远端地址一致 - 避免在
cmd/或internal/子目录里执行make build—— 即使 Makefile 在根目录，go build仍以当前目录为起点 - 最保险写法：每条
go命令前加cd $$(dirname $$(realpath $(MAKEFILE_LIST))) &&
真正难的不是写几行 go build，而是让不同人、不同机器、不同 CI 节点跑出完全一致的结果。Makefile 的价值不在语法多炫，而在把那些“应该这么做但总有人漏掉”的细节钉死。比如 CGO_ENABLED=0、export PATH、mkdir -p bin/ —— 它们琐碎，但缺一不可。
