go version无响应需先确认PATH是否生效：Windows须彻底关闭再重开终端，macOS/Linux需source配置文件并检查echo $PATH输出是否含Go路径，再用which go或where go验证。
go version 命令没反应？先确认 PATH 是否真生效
安装完 go 后执行 go version 报 “command not found” 或直接无输出，大概率是 PATH 没配对。Windows 用户用 .msi 安装包虽会自动写系统变量，但必须**重启 CMD/PowerShell** —— 不是“新开一个窗口”，而是彻底关闭再重开，否则环境变量不加载。
macOS/Linux 用户常见错误是只改了 ~/.zshrc 却忘了 source ~/.zshrc；或者用了 bash 终端却去改 zshrc。验证方式很简单：
- 运行
echo $PATH，确认输出里含/usr/local/go/bin（macOS/Linux）或C:\Go\bin（Windows 默认路径） - 运行
which go（macOS/Linux）或where go（Windows），应返回具体路径 - 若仍失败，别急着重装，先检查安装目录是否存在
go可执行文件
GOOS=linux GOARCH=amd64 编译出的二进制为什么在目标机器上跑不起来？
交叉编译本身没问题，但容易忽略两个隐性依赖：
-
CGO_ENABLED=0必须显式关闭：默认开启时会链接 libc，导致编译出的 Linux 二进制在 Alpine 等精简镜像里报not found错误。正确命令是：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app-linux . - 目标系统内核版本太老：比如用 Go 1.25 编译的二进制，在 CentOS 6（glibc 2.12）上可能因符号缺失崩溃。建议生产环境用 Go 1.21–1.24 LTS 版本，兼容性更稳
- 注意
GOARM：树莓派等 ARM 设备需额外指定GOARM=7或GOARM=8，否则默认生成 ARMv6 兼容码，性能差且可能不兼容新硬件
go mod init 失败提示 “working directory is not part of a module” 怎么办？
这不是权限或路径问题，而是当前目录没有被识别为模块根。Go 1.16+ 默认启用模块模式，但 go mod init 要求目录名能构成合法导入路径（不能含空格、中文、点号开头、或以 _ . 开头）。
立即学习“go语言免费学习笔记（深入）”；
典型错误场景：
- 项目建在桌面，路径是
/Users/name/Desktop/my project→ 空格导致解析失败 - 目录名是
.myapp或_utils→ Go 拒绝初始化模块 - 父目录已有
go.mod，而你 cd 进了子目录再 init → Go 认为你在子模块里，不允许重复 init
解决方法：换一个干净路径，比如 ~/go/src/github.com/yourname/app，然后运行 go mod init github.com/yourname/app。模块名不必真实存在，但要符合 URL 格式。
国内拉包超时或 go get 报 403，代理配置对了还失败？
配置 GOPROXY 是基础，但三个参数必须协同生效：
-
GO111MODULE=on：强制启用模块模式，否则go get会走老式 GOPATH 模式，绕过代理 -
GOPROXY=https://goproxy.cn,direct：逗号分隔的 fallback 链，direct表示代理查不到时回源官方，不能漏掉 -
GOSUMDB=sum.golang.org→ 改成GOSUMDB=off或sum.golang.google.cn：否则校验和服务器连不上，go get会卡死或报错
验证是否全生效：运行 go env | grep -E 'GO111MODULE|GOPROXY|GOSUMDB'，三者都应有值。如果仍失败，临时加 -v 参数看详细日志：go get -v github.com/gin-gonic/gin，常能暴露是代理转发失败还是 sumdb 拒绝连接。
跨系统编译真正麻烦的不是命令本身，而是 runtime 依赖和符号兼容性。哪怕 GOOS/GOARCH 对了，CGO_ENABLED 和 GOSUMDB 的开关状态稍有偏差，就可能让二进制在目标环境静默崩溃。
