多环境构建与发布：gf build/交叉编译

面试问法：GoFrame 项目怎么编译出不同平台的产物？开发、测试、生产环境配置怎么隔离？ 一句话结论：交叉编译用 gf build（底层仍是 go build + GOOS/GOARCH 环境）或手写 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build；多环境隔离靠“同一套代码 + 不同配置文件”，运行时通过环境变量/启动参数选择要加载的 config 文件。

gf build 用法

# 官方 CLI：默认按目标环境编译（参数以 gf build -h 与官方文档为准）
gf build main.go

# 常见形态：指定产物名/架构/系统
gf build main.go -n myapp -a amd64 -s linux -p out/

# 等价的纯 go 写法（服务端静态编译，无运行依赖）
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o main main.go

• gf build 与手写 go build 二选一即可，产物都是单文件。
• 交叉编译遇到依赖 CGO 的库时需处理 CGO 工具链，纯 Go 代码 CGO_ENABLED=0 最省事。
• 发布时把可执行文件连同配置文件（及静态资源目录）一起发布，工作目录与配置目录要一致。

多环境配置隔离

• 准备多份配置文件：config.yaml（开发默认）、config.prod.yaml（生产）等。
• 运行时切换：通过环境变量或启动参数指定实际加载的文件（如 GF_GCFG_FILE=config.prod.yaml，变量名以官方文档为准）。
• 敏感项（数据库密码、密钥）走环境变量注入或密钥管理，不写进仓库。
• CI/CD 里按环境设置对应变量并执行交叉编译即可发布；gf build 的版本号等参数可用于产物标识（细节以 gf build -h 为准）。

常见追问

• 追问：多环境为什么不用 build tag？——配置是运行期维度，编译期 tag 会导致“一个环境一个二进制”，违背“构建一次、多处部署”的实践；配置外置更利于镜像复用与审计。
• 追问：gf build 和 go build 有区别吗？——本质一致，gf build 只是封装了常用参数与默认行为；CI 里直接 go build + 显式 GOOS/GOARCH 同样标准。

记忆点

• 编译：gf build 或 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build。
• 环境：一套代码 + config.*.yaml + 运行环境变量切换文件。