go run 编译后立即运行并清理临时二进制；go install 编译后将可执行文件复制到 $gobin 或默认 $gopath/bin 供全局调用，且要求 package main。
Go 开发环境在 2026 年已基本无需手动配 GOPATH，但 GOROOT、GOPROXY 和模块初始化仍是编译失败的高频原因。
go install 和 go run 的行为差异在哪
两者都执行编译，但目标和生命周期完全不同：go run 编译后立即运行并清理临时二进制；go install 编译后将可执行文件复制到 $GOPATH/bin 或 $GOBIN（若已设置），供全局调用。
-
go run main.go：适合快速验证逻辑，不生成持久文件，无法跨目录调用 -
go install ./cmd/mytool：要求项目含package main，且路径下有main.go，生成的二进制会落在$GOBIN或默认$GOPATH/bin - 如果
GOBIN未设置，go install仍会写入$GOPATH/bin，但该目录必须在PATH中才可直接执行 - Go 1.21+ 默认启用模块模式，
go install从远程路径安装（如go install github.com/xxx/cli@latest）时，不再依赖本地GOPATH
go build 编译出的二进制为什么不能直接运行
常见原因是静态链接未启用，导致运行时报 cannot execute binary file: Exec format error 或缺失动态库（尤其在交叉编译或容器内运行时）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- Linux 下默认使用 cgo，依赖系统 glibc；若目标环境无对应版本（如 Alpine），需禁用 cgo：
CGO_ENABLED=0 go build -o myapp - Windows 编译 Linux 二进制需显式指定：
GOOS=linux GOARCH=amd64 go build -o myapp -
go build -ldflags="-s -w"可减小体积并去除调试信息，但不会解决架构/ABI 不兼容问题 - 用
file myapp查看二进制类型，确认是否匹配目标平台（如ELF 64-bit LSB executable, x86-64）
go env -w 配置被忽略的典型场景
go env -w 写入的是 Go 自己维护的配置文件（$HOME/go/env），但它可能被 shell 环境变量、IDE 设置或 CI 脚本覆盖。
- 终端中已通过
export GOPROXY=...设置了同名变量，它会优先于go env配置 - VS Code 的 Go 扩展可能读取自己的
settings.json中的"go.toolsEnvVars"，绕过go env - 某些 CI 环境（如 GitHub Actions）中，
go env -w写入的文件不在工作流缓存路径里，每次 job 都是干净状态 - 验证是否生效：运行
go env GOPROXY，而非echo $GOPROXY—— 后者查的是 shell 变量
模块初始化后 go get 仍失败怎么办
即使 go mod init 成功，go get 报错往往不是模块本身问题，而是代理或校验机制拦截。
- 国内最稳组合是：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOSUMDB=off（仅开发机，生产慎用） -
GOSUMDB=off关闭校验可绕过sum.golang.org连接失败，但会丢失依赖完整性保护 - 若用私有仓库（如 GitLab），需额外配
go env -w GOPRIVATE=gitlab.example.com，否则代理会尝试转发 -
go get -u在 Go 1.22+ 已不推荐，改用go get example.com/pkg@latest显式指定版本更可控
真正容易被忽略的是：Go 命令行工具链（如 gopls、dlv）的版本与当前 Go SDK 版本不匹配时，go install 安装的二进制可能无法被 IDE 正确识别——这不是环境变量问题，而是工具链语义版本漂移。建议始终用 @latest 安装，并定期 go install 更新。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
