go build直接生成可执行文件，但需当前目录含package main和func main()；默认输出名为目录名（Windows为main.exe，Linux/macOS为main），-o可指定路径与名称，跨平台需设GOOS/GOARCH。
直接用 go build 就能生成可执行文件，不需要额外工具或配置；但生成结果是否可用，取决于当前环境变量和代码结构。
go build 默认行为：只看当前目录的 main 包
运行 go build 时，它会自动查找当前目录下所有 .go 文件，只要其中包含 package main 和 func main()，就能编译出可执行文件。
- 在 Windows 上，默认输出名是
main.exe；Linux/macOS 下是main（无后缀） - 如果当前目录没有
main包，会报错：no Go files in ...或build: no non-test Go files - 若项目用了 Go Modules，
go build会自动解析go.mod中的依赖并静态链接，不依赖外部GOROOT或GOPATH - 不要在子目录里乱跑
go build—— 比如你在cmd/myapp/目录下，得确保该目录下有main.go，否则它不会“向上找”主包
指定输出名和路径：-o 参数必须跟对目标
-o 控制最终生成的文件名和位置，但它不改变编译源；你仍得保证命令执行时工作目录或参数指向了含 main 包的路径。
- 正确：
go build -o ./dist/mytool.exe ./cmd/mytool（./cmd/mytool是模块内含main的包路径） - 错误：
go build -o ./dist/mytool.exe ./pkg/utils（utils是普通库包，没main函数）→ 报错cannot build package in ... (not a main package) - 省略
-o时，输出名默认取自包路径最后一段：比如go build ./cmd/mytool→ 输出mytool（或mytool.exe） -
-o后路径支持相对或绝对，但父目录必须已存在，否则报no such file or directory
跨平台生成 Windows .exe：GOOS=windows 不是可选项
在 Linux 或 macOS 上运行 go build -o app.exe，生成的仍是 ELF 或 Mach-O 格式，双击打不开、属性里看不到“兼容性”选项——这不是后缀问题，是二进制格式根本不匹配。
- 必须显式设置：
GOOS=windows GOARCH=amd64 go build -o app.exe ./cmd/myapp -
GOARCH=amd64强烈建议带上，避免某些 Go 版本默认用386（Win10/11 默认不带 32 位子系统） - PowerShell 用户别用
export GOOS=windows，改用：$env:GOOS="windows"; $env:GOARCH="amd64"; go build -o app.exe ./cmd/myapp - 如果代码用了
os/user、netDNS、或syscall调 Win32 API，CGO_ENABLED=0可能导致功能退化或崩溃；需权衡是否关闭
常见失败原因：main 包位置和模块初始化
很多“编译成功但运行报错”或“根本编译不过”，其实卡在两个低级但高频的点上。
- 项目根目录没
go.mod，且main.go在子目录（如cmd/app/main.go），直接在根目录跑go build→ 找不到main包。解决：先go mod init myproject，再用go build ./cmd/app -
main.go和helper.go在同一目录，但helper.go里写了package utils→ 编译报错package utils is not in GOROOT。解决：同目录所有文件必须声明package main - 用了
embed.FS或//go:embed，但 Go 版本 unknown directive - Go 1.22+ 默认启用
GO111MODULE=on，但如果当前路径在$GOPATH/src下且无go.mod，可能意外进入 GOPATH 模式，导致依赖解析异常
最易被忽略的是：交叉编译时 GOOS 和 GOARCH 必须成对生效，且不能靠文件后缀“蒙混过关”。Windows 的 PE 头、导入表、入口点都是编译期硬生成的，不是加个 .exe 就算数。真要发给用户，务必在目标系统上双击验证一次。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
