go build报错找不到包大概率因goproxy未配或配置错误，国内需设为https://goproxy.cn,direct并启用go111module=on；alpine运行报“no such file or directory”实为libc不兼容，须加cgo_enabled=0跨平台编译。
go version 能跑，但 go build 报错找不到包
大概率是 GOPROXY 没配或配错了。国内默认直连 proxy.golang.org 会超时或失败，go get 和 go build 依赖模块时就会卡住或报 cannot find module。
执行这三条命令（Windows PowerShell 或 CMD）：
go env -w GO111MODULE=ongo env -w GOPROXY=https://goproxy.cn,directgo env -w GOSUMDB=sum.golang.org
验证是否生效：go env | findstr GOPROXY（Windows）或 go env | grep GOPROXY（macOS/Linux），输出应含 https://goproxy.cn。不生效就重启终端——这是新手最常漏的一步。
go build 生成的文件在 Linux 上运行报 No such file or directory
这不是路径错了，而是二进制动态链接了宿主机 libc，目标 Linux 环境缺对应解释器（比如 glibc vs musl）。尤其在 Alpine 容器里必现。
跨平台编译必须加 CGO_ENABLED=0：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app-linux main.go- 若用 Windows/macOS 编译 ARM64 Linux 版：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-arm64 main.go
不加 CGO_ENABLED=0 时，只要代码里 import "net" 或 "os/user" 就可能触发 cgo，导致生成的文件依赖目标系统 C 工具链——而你根本没装。
go run 和 go build 的输出文件名规则不同
go run main.go 不生成任何文件，只执行；go build 默认按目录名或主文件名生成可执行文件，容易混淆。
-
go build main.go→ 输出main（Linux/macOS）或main.exe（Windows） -
go build（当前目录有go.mod）→ 输出文件名 =go.mod中module行的最后部分（如module github.com/user/project→ 输出project） -
go build -o myapp main.go→ 明确输出myapp（Linux/macOS）或myapp.exe（Windows）
Windows 下 -o 必须带 .exe 后缀才可双击运行；Linux/macOS 不需要后缀，但加了也无害。
验证编译结果是不是真静态链接
别信文件名或 file 命令的“ELF”字样，要实测：
-
file myapp-linux应显示statically linked -
ldd myapp-linux应输出not a dynamic executable - 扔进最小化环境跑：
docker run --rm -v $(pwd):/work -w /work alpine:latest ./myapp-linux
只要报 No such file or directory，基本就是 cgo 没关干净，或者 GOOS/GOARCH 和目标机器不匹配。每次换平台，都得重走一遍 CGO_ENABLED=0 + 容器验证流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
