不是，go build -ldflags="-s -w" 仅剥离符号表和调试信息，不改变链接方式；Go 默认静态链接（无cgo时），验证需用 file 或 ldd 检查是否显示 statically linked。
go build -ldflags="-s -w" 是静态链接吗？
不是。这两个参数只是剥离调试符号和 DWARF 信息，不改变链接方式。go build 默认就是静态链接（除少数 cgo 依赖外），但很多人误以为要加 -ldflags=-extldflags=-static 才算“真正静态”。实际上只要没启用 cgo，生成的二进制天然无 libc 依赖。
验证方法：在 Windows 或 Linux 上用 file 或 ldd 检查输出文件：
file ./myapp
看到 statically linked 才是真的静态；若显示 dynamically linked，说明触发了 cgo（比如用了 net 包的 DNS 解析、os/user 等）。
-
CGO_ENABLED=0 go build强制禁用 cgo，确保纯静态 - Windows 下默认禁用 cgo，所以
go build出来基本都是静态的 - Linux/macOS 下
net包默认走 cgo，想静态就得设CGO_ENABLED=0，此时 DNS 会 fallback 到纯 Go 实现（netgo）
如何让 go build 输出真正可移植的静态二进制？
关键不是“怎么加参数”，而是“怎么避免踩 cgo 的坑”。很多开发者加了一堆 -ldflags 却仍无法脱离系统 libc，根源在隐式 cgo 调用。
立即学习“go语言免费学习笔记（深入）”；
- 先确认是否用了 cgo 依赖：检查 import 中是否有
"C"、"net"（尤其net.ResolveIPAddr）、"os/user"、"os/signal"（某些信号处理）、"syscall" - 临时禁用 cgo 编译：
CGO_ENABLED=0 go build -o app .，再用ldd app验证（Linux）或otool -L app（macOS） - 如果必须用 cgo（如调用 C 库），又想静态，Linux 需额外安装
musl-gcc并指定：CC=musl-gcc go build -ldflags="-linkmode external -extldflags '-static'"—— 这属于高级场景，日常开发几乎不用
GOROOT 和 GOPATH 在 Go 1.16+ 还需要手动配吗？
GOROOT 通常不需要手动设 —— 安装程序（尤其是 Windows .msi 或 macOS .pkg）已自动写入 PATH 并隐式设置 GOROOT；GOPATH 更是基本废弃了。
- Go Modules 启用后（
go mod init之后），模块查找只看go.mod和本地缓存（$GOPATH/pkg/mod），不再扫描$GOPATH/src - 唯一还可能用到 GOPATH 的场景：运行
go install安装命令行工具，它默认输出到$GOPATH/bin；你可以用go install -o ./bin/mytool绕过，或直接设GOBIN=./bin - 检查当前生效路径：
go env GOROOT GOPATH GOBIN，多数情况下GOPATH显示为$HOME/go但实际不参与构建逻辑
国内环境下 go get / go install 总失败怎么办？
根本原因是模块代理（proxy）没设对，不是网络问题本身。Go 1.13+ 默认启用了模块代理，但官方 proxy（proxy.golang.org）在国内不稳定。
- 设国内镜像代理：
go env -w GOPROXY=https://goproxy.cn,direct（推荐，支持私有模块回源） - 若项目含私有 Git 仓库（如公司内网 GitLab），在
direct前加例外：go env -w GOPROXY=https://goproxy.cn,https://goproxy.io,direct，然后设go env -w GOPRIVATE=git.example.com - 临时绕过代理只对某次命令生效：
GOPROXY=direct go get github.com/some/private/repo - 注意：
go install命令（如go install golang.org/x/tools/gopls@latest）同样走 proxy，别漏配
静态链接和环境配置里最常被忽略的，其实是 cgo 的隐式开关和模块代理的 direct 回源逻辑 —— 这两处一错，编译能过，运行或部署时才暴露问题。
