不需要安装 go 运行时；go 编译默认静态链接，将运行时、gc、调度器和标准库全部打包进二进制文件，生成的可执行文件在匹配的操作系统和架构上可直接运行，仅启用 cgo 且调用系统 c 库时才可能引入额外动态依赖。
不需要安装 Go 环境，Go 编译出的二进制文件本身就是自包含的可执行体——只要操作系统和架构匹配，直接运行即可。
为什么不用装 Go 运行时
Go 默认使用静态链接：go build 会把 runtime、GC、调度器、标准库全部打包进最终文件。生成的 myapp.exe（Windows）或 myapp（Linux/macOS）不依赖 goruntime.dll、libgo.so 或任何 Go SDK 组件。
- 验证方式：在没装 Go 的机器上双击
myapp.exe或执行./myapp，只要没报“找不到某某 DLL”或“not found”，就说明它自己带齐了所有东西 - 例外仅出现在启用
CGO_ENABLED=1且调用了系统 C 库（如net包 DNS 解析、os/user）时，此时可能依赖vcruntime140.dll（Windows）或libc.so.6（Linux glibc） - 纯 Go 实现 + 默认构建 = 零 Go 依赖
常见运行失败的真正原因
报错不是因为缺 Go，而是系统级依赖缺失或权限/路径问题：
-
Command not found（Linux/macOS）：没加./前缀，或缺少可执行权限 → 运行chmod +x myapp -
无法找到指定的模块（Windows）：实际是缺vcruntime140.dll或msvcp140.dll→ 安装 Microsoft Visual C++ 2015–2022 Redistributable -
panic: lookup xxx: no such host（Windows）：启用了 CGO 后调用系统 DNS，但目标机网络策略限制 → 改用go build -tags netgo强制内置 DNS 解析 - Alpine Linux 上报
not found：glibc 二进制试图加载ld-linux-x86-64.so.2，而 Alpine 用的是 musl → 改用CGO_ENABLED=0 go build，或手动建符号链接（不推荐）
确保真正“免依赖”的编译方式
发布前用这几条命令锁定静态行为：
- 禁用 CGO：
CGO_ENABLED=0 go build -o app main.go（Windows CMD：先set CGO_ENABLED=0再go build） - 剥离调试信息 & 符号表（减体积、防逆向）：
go build -ldflags="-s -w" -o app main.go - Windows GUI 程序隐藏控制台窗口：
go build -ldflags="-H windowsgui -s -w" -o app.exe main.go - 交叉编译到其他平台：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 main.go
编译完用 file app（Linux/macOS）或 dumpbin /dependents app.exe（Windows）检查是否只剩系统核心 DLL（如 kernel32.dll），没有第三方或 Go 相关依赖项。
scratch 容器里跑不起来？别怪 Go，怪你没关 CGO
Docker scratch 是空镜像，连 /bin/sh 都没有。如果 Go 程序启用了 CGO，它会在运行时尝试加载 glibc 动态链接器——而 scratch 根本没有这个文件。
- 正确做法：构建阶段就禁用 CGO：
CGO_ENABLED=0 go build -o server . - 错误做法：在
scratch里硬塞ld-musl或改链接路径——破坏了 scratch 的轻量初衷 - 验证：
docker run --rm -it your-scratch-image /server能输出结果，且docker image ls显示镜像大小 ≈ 2–7 MB，说明成功了
真正容易被忽略的点是：CGO 不是“用了才开”，而是“没显式关就默认开”（Linux/macOS 下），Windows 默认关但一旦引入 cgo 代码（哪怕只是一行 #include）就会触发。交付前务必确认 CGO_ENABLED=0 是否生效。
