真装好了需三步闭环验证：下载匹配架构的二进制包、显式配置goroot=/usr/local/go且$goroot/bin置于path开头、设置goproxy=https://goproxy.cn,direct；仅go version成功不算数。
Linux 服务器上装 Go，不用折腾源码编译，直接解压二进制包 + 配环境变量就能跑起来；但 PATH 没生效、GOROOT 指向错、go mod init 失败——这三类问题占了新手踩坑的 90%。
怎么验证 go 命令真能用，不是“看起来能用”
很多人执行 go version 成功就以为完事了，其实只是 shell 缓存了旧路径或 alias。真正要确认的是：which go 输出是否指向 /usr/local/go/bin/go（或你解压的实际路径），且 go env GOROOT 返回值和解压目录一致。
- 如果
which go报错或返回空，说明PATH没生效，检查~/.bashrc是否被正确加载（source ~/.bashrc后再试） - 如果
go env GOROOT是空或指向错误路径（比如/home/xxx/go），说明没设或设错了——Go 1.21+ 默认会自动推导，但手动设错会覆盖它 - 运行
go env -w GOROOT=""可清空手动设置，让 Go 自行判断
go run 和 go build 行为差异直接影响调试节奏
go run main.go 是临时编译并执行，不生成文件；go build 生成可执行文件，默认名就是当前目录名（非 main.go 文件名）。两者都要求当前目录下有且仅有一个 package main 文件。
- 常见错误：
go run *.go在多文件项目里会失败，因为 Go 不允许同时指定多个main包入口 - 想生成指定名字的二进制：用
go build -o myapp，而不是依赖默认名 -
go run无法调试符号（如用dlv），必须用go build -gcflags="all=-N -l"再运行 - 跨架构构建（比如在 x86_64 上编译 arm64 程序）需要显式设
GOOS和GOARCH，go run不支持
go mod init 报 “cannot find module providing package” 怎么办
这不是网络问题，而是模块初始化时没识别到当前路径是干净项目根目录。最典型场景：你在 ~/go/src/github.com/user/project 下执行 go mod init，但 GOPATH 已废弃，Go Modules 会忽略 src 这层路径。
- 正确做法：cd 到项目根（即你要放
go.mod的地方），确保该目录下没有go.mod，再运行go mod init example.com/project（模块名可以是假域名，但不能是main或空） - 如果已有
go.mod但内容混乱，直接删掉重来，别用go mod edit修 - 引入本地包（比如
./utils）前，先确保该子目录里有至少一个.go文件且package名不是main -
go mod tidy会自动补依赖，但如果import路径写成github.com/some/repo/v2而对方没打 v2 tag，就会报错——这时得查对方仓库真实 tag
Linux 下权限与路径写错导致静默失败
解压 Go 到 /usr/local 必须用 sudo tar，但后续所有开发操作都不该用 sudo。最常被忽略的是：普通用户对 /usr/local/go 没写权限，一旦误执行 go install 或 go get，会卡住或报 permission denied 而不提示具体路径。
- 永远用
go install -v ./...替代go get（后者已弃用） -
GOBIN推荐设为$HOME/go/bin，而非系统级路径，避免权限冲突 - 如果
go build后生成的二进制无法执行（Permission denied），先ls -l看文件权限，Linux 默认不给脚本加可执行位，但 Go 生成的二进制应该有，若没有，说明文件系统挂载时用了noexec - 某些容器或最小化系统（如 Alpine）缺
libc，静态链接需加CGO_ENABLED=0，否则运行时报not found
真正麻烦的不是装不上，而是装上了却在某个环节悄悄绕过预期路径——比如 go env 显示的 GOPATH 其实已被 Modules 模式忽略，但旧教程还在教你怎么配它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
