go 原生 `go build` 不支持自动执行自定义构建脚本，但可通过 `go:generate` 预处理、makefile 封装或构建脚本等方式灵活扩展，兼顾可维护性与工具链兼容性。
Go 的构建工具链（go build/go install/go get）设计哲学强调简洁与一致性，因此不提供钩子机制或插件式扩展能力来运行任意外部命令。这意味着你无法像在 Make、CMake 或 Bazel 中那样，在 go build 执行前后自动触发 protoc 生成代码、资源打包、版本注入或静态文件编译等操作。
不过，Go 提供了若干务实的替代方案，可根据项目类型和协作需求选择：
✅ 推荐方案一：使用 go:generate 进行源码预处理
自 Go 1.4 起引入的 go generate 是官方支持的预构建机制——它不自动运行，需显式调用 go generate，但语义清晰、可版本控制且与 go mod 兼容良好。
示例：自动生成 Protocol Buffer 绑定代码
//go:generate protoc --go_out=. --go-grpc_out=. ./api/service.proto package api import "fmt"
执行时运行：
go generate ./... go build
⚠️ 注意：go generate 不会被 go build、go get 或 go install 自动触发，必须单独调用；建议将其写入 CI 脚本或 Makefile 中确保一致性。
✅ 推荐方案二：封装为 Makefile（主流工程实践）
绝大多数需要复杂构建逻辑的 Go 项目（如 Kubernetes、Docker、Terraform）均采用 Makefile 统一入口。它不破坏 Go 工具链，反而提升可复现性与跨平台兼容性。
示例 Makefile 片段：
.PHONY: build generate test
generate:
go generate ./...
build: generate
go build -ldflags="-X 'main.Version=$(shell git describe --tags)'" -o bin/app .
test:
go test -v ./...
clean:
rm -f bin/app开发者只需执行 make build，即可完成代码生成 + 构建 + 版本注入全流程。
⚠️ 注意事项与最佳实践
- 库（library）优先保持 go get 友好：避免依赖 go:generate 或外部工具，确保下游用户能直接 go get 并立即构建；若必须生成代码，请将生成结果提交至仓库（如 pb.go 文件）。
- 避免修改 go build 行为本身：// #cgo ... 仅用于 C 依赖声明，不可用于执行任意 shell 命令；试图通过 hack CGO_CFLAGS 等环境变量注入构建逻辑属于反模式。
- CI/CD 中显式声明步骤：在 GitHub Actions、GitLab CI 等环境中，应明确拆解 generate → test → build → package 流程，而非依赖隐式钩子。
总之，Go 不是通用构建系统，但其“约定优于配置”的设计鼓励你用简单、透明、可审计的方式组织构建流程——go:generate 处理源码生成，Makefile 或 bash 脚本协调多步任务，二者结合，既符合 Go 生态规范，又不失工程灵活性。
