关键不是“哪个更好”，而是“目标是否匹配”：go build用于本地调试和指定路径构建，生成文件不修改PATH；go install专为安装全局命令设计，要求module路径合法且包为main，将二进制放入$GOBIN（需确保其在PATH中）。
用 go build 或 go install 构建 Go 项目，关键不是“哪个更好”，而是“目标是否匹配”：本地调试、批量命令生成、跨平台发布、还是安装为全局命令——选错命令会导致二进制找不到、路径混乱、甚至构建失败。
go build -o 指定输出路径，别碰 go build ./
执行 go build ./ 看似省事，实际会污染源码树且行为不可控。它只扫描当前目录下一级的包，不会递归进 cmd/serve 这类嵌套结构；更糟的是，它会在每个含 main 包的子目录里生成同名可执行文件（比如在 ./cmd/serve/ 下生成 serve），这不是部署所需。
- 调试阶段推荐：
go build -o ./bin/mycmd ./cmd/mycmd，明确输出到bin/目录，不污染源码 - 想一次构建多个命令（如
cmd/serve和cmd/migrate）？用go list -f '{{.ImportPath}}' ./cmd/...动态获取路径再循环构建，别硬写死 -
go build默认不修改$PATH，生成的文件必须带路径运行（如./bin/serve），不能直接敲serve
go install 要求 module 路径合法，且只认 main 包
go install 不是 go build 的“升级版”，它是专为安装命令设计的：把二进制放进 $GOBIN（默认 $HOME/go/bin），并要求你项目有合法的 module 声明（如 module example.com/myapp）和正确的包结构。
- 如果
go install ./cmd/serve报错cannot install non-main package，检查./cmd/serve/main.go是否声明了package main，且该目录下没有其他非main包混入 - 如果报错
no Go files in ...，说明那个cmd/*子目录里压根没main.go，或文件权限不对，或被.gitignore误排除 - Go 1.21+ 默认关闭 GOPATH 模式，
$GOBIN必须提前加进$PATH，否则装完也调用不到
交叉编译时 -ldflags 注入版本号容易静默失效
用 GOOS=windows GOARCH=amd64 go build 交叉编译时，常加 -ldflags="-X main.version=1.0.0" 注入版本信息——但这个变量必须真实存在于被构建的 main 包里，否则链接器不会报错，只会让 main.version 保持空字符串。
立即学习“go语言免费学习笔记（深入）”；
- 如果版本变量定义在
internal/version/version.go，注入时必须写全路径：-X github.com/yourname/myapp/internal/version.Version=1.0.0 -
GOOS=windows时输出文件自动带.exe后缀；GOOS=linux或darwin则无后缀，别在-o里硬编码myapp.exe - 标准库依赖（如
net/http）在交叉编译时仍需匹配目标系统，某些 cgo 依赖可能直接失败，建议先禁用：CGO_ENABLED=0
Makefile 封装构建时，避免写死路径和 ./
用 Makefile 自动化构建，最常见错误是直接写 go build ./ 或固定路径如 go build ./cmd/serve。前者不可靠，后者难维护——新增一个 cmd/cli 就得改 Makefile。
- 用
go list -f '{{.ImportPath}}' ./cmd/...动态列出所有cmd/*下的 main 包路径，再逐个go install或go build -o - 区分开发与发布目标：比如
make dev用go build -o ./bin/...，make release用GOOS=linux CGO_ENABLED=0 go build -o ./dist/... - 别在 Makefile 里 echo “构建完成”，真正要检查的是
./bin/下文件是否存在、是否可执行、./dist/下文件大小是否 >0
真正麻烦的从来不是命令本身，而是路径、模块声明、包名、环境变量这四者之间的隐式耦合——任何一个对不上，go install 就会拒绝工作，而 go build 可能悄悄生成错地方的文件，等上线才发现根本没跑对服务。
