最直接有效的方式是使用 -o 参数显式指定输出路径；Go 不支持全局输出目录配置，GOPATH 和 GOBIN 对 go build 无效，且 go run 不支持 -o。
go build -o 指定输出路径是最直接有效的方式
Go 本身不提供全局“输出目录”配置项，go build 默认把二进制写到当前目录。想控制位置，必须显式用 -o 参数指定完整路径或相对路径。
常见错误是误以为设置 GOPATH 或 GOBIN 能影响 go build 输出——它们只对 go install 生效；而 go build 完全无视这些环境变量。
-
go build -o ./bin/myapp ./cmd/api：生成可执行文件到项目下的./bin/myapp -
go build -o /tmp/app ./cmd/cli：输出到系统临时目录（注意权限） - 路径中含不存在的父目录会报错，需提前创建：
os.MkdirAll("bin", 0755)或手动mkdir -p bin
多命令项目下避免 -o 写死，改用 Makefile 或脚本封装
当项目有 cmd/api、cmd/worker、cmd/cli 多个入口时，每个 go build -o 命令单独写容易漏、难维护。硬编码路径也导致跨环境迁移失败（比如 macOS 和 Linux 的 /usr/local/bin 权限策略不同）。
推荐做法是用 Makefile 统一管理输出逻辑：
build: \tgo build -o ./dist/api ./cmd/api \tgo build -o ./dist/worker ./cmd/worker \tgo build -o ./dist/cli ./cmd/cli
这样执行 make build 就能批量生成，且 ./dist/ 可加进 .gitignore，不污染 Git。
- 不要在
go.mod或go.env里试图“配置输出目录”，无效 - CI/CD 中建议用绝对路径（如
$(PWD)/dist），避免因工作目录切换导致路径错乱 - 若用
go install，它会把二进制放到GOBIN（或默认$GOPATH/bin），但要求模块已发布或本地 replace，不适合日常构建
go run 不支持 -o，调试阶段别指望它输出文件
go run 是纯内存编译+执行，不会落盘。你写 go run -o ./out main.go 会直接报错：flag provided but not defined: -o。
如果开发中需要反复运行又想保留二进制（比如测启动耗时、检查符号表），只能切回 go build -o + 手动执行，或者用 shell 别名简化：
alias gbu='go build -o ./tmp/app && ./tmp/app'
-
go run本质是临时构建，适合快速验证逻辑，不是构建流程一环 - 某些 IDE 插件（如 GoLand）的 “Run” 按钮底层调的仍是
go run，所以点击运行永远看不到输出文件——这是设计使然，不是配置问题 - 想让 IDE 启动时自动构建并运行指定输出路径？得改 Run Configuration 里的 “Program path”，指向你用
go build -o生成的文件
注意 Windows 下的 .exe 后缀和路径分隔符差异
在 Windows 上，go build -o ./dist/app 实际生成的是 ./dist/app.exe，而 Linux/macOS 不带后缀。如果脚本里硬编码了 ./dist/app 并期望它可执行，Windows 会失败。
更隐蔽的问题是路径分隔符：filepath.Join("dist", "app") 自动处理 / vs \，但手写字符串如 "dist/app" 在 Windows 上可能被解释为当前盘符根目录下的 app（尤其用 os.Chdir 后）。
- 跨平台构建脚本中，一律用
filepath.Join()拼路径，别拼字符串 - 判断二进制是否存在时，Windows 要检查
app.exe，其他系统检查app；可用exec.LookPath代替手动判断 - CI 中若用 GitHub Actions 的
runs-on: windows-latest，记得在-o后加.exe后缀，否则后续run步骤找不到文件
实际构建输出路径这件事，核心就一条：Go 不抽象“输出目录”概念，只认 -o 参数。所有试图绕过它的配置（比如改 GOROOT、塞 build tags、动 go.env）都会失效。真正容易被忽略的是 Windows 的后缀隐式添加和路径分隔符陷阱——它们不会报错，但会让脚本在某个平台静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
