必须设GOPROXY是因为国内无法访问默认代理https://proxy.golang.org，会导致go mod download、go get等命令超时或失败；设为https://goproxy.cn,direct可确保依赖正常拉取。
go 环境能跑起来、go build 能编译出多个目标平台的二进制，这件事本身不难，但卡点往往在代理、模块初始化和交叉编译参数组合上。只要避开这几个坑，10 分钟内完成是常态。
go env -w GOPROXY 为什么必须设？
国内直接走 https://proxy.golang.org 会超时或返回 403，go mod download 或 go get 就卡住不动，连 go run 都可能失败（尤其首次拉 fmt 以外的包时）。
- 设成
https://goproxy.cn,direct是最稳妥的国内选择 - 执行命令：
go env -w GOPROXY=https://goproxy.cn,direct - 验证是否生效：
go env GOPROXY应输出该地址 - 如果用的是旧版 Go（go env -w GO111MODULE=on
go mod init 后 go build 编译失败？
常见报错：cannot find module providing package ... 或 build failed: no Go files in current directory —— 这不是环境问题，而是项目结构没对齐。
-
go mod init必须在项目根目录下执行，且该目录下要有至少一个.go文件（比如main.go） - 如果文件在子目录（如
cmd/app/main.go），就 cd 进去再go mod init example.com/app -
go build默认只编译当前目录下的main包；若想编译子目录，得显式指定路径：go build ./cmd/app - 多
main包共存时（如 CLI + HTTP server），每个都要单独go build -o ./bin/cli ./cmd/cli，不能靠通配符一次全编
GOOS=linux GOARCH=arm64 go build 总是生成 darwin 二进制？
环境变量没生效，或者被 shell 缓存/覆盖了。交叉编译对变量敏感，错一个字母或空格就退回到本地平台。
- 确认写法：
GOOS=linux GOARCH=arm64 go build -o myapp main.go（变量在命令前，**不能**用export后再go build，除非你确定没被其他脚本重置） - ARM 架构要额外注意：
GOARCH=arm时必须加GOARM=7；GOARCH=arm64则不需要 - 检查结果：
file myapp应显示类似ELF 64-bit LSB executable, ARM aarch64，而不是Mach-O 64-bit executable x86_64 - 静态链接保险起见加
CGO_ENABLED=0：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o server main.go
go run 和 go build 输出路径不一致？
go run 是临时编译并执行，不会留下文件；go build 默认把可执行文件放在当前目录。很多人误以为它们行为对称，结果找不到生成的二进制。
立即学习“go语言免费学习笔记（深入）”；
-
go run main.go→ 执行完就删掉临时文件 -
go build→ 当前目录生成同名可执行文件（如main或myapp） - 指定输出路径用
-o：go build -o ./bin/app main.go，否则容易和源码混在一起 - Windows 下默认输出
main.exe，Linux/macOS 是main，名字不带后缀；跨平台部署时建议固定用-o
