“command not found”错误源于PATH未正确包含Go的bin目录，需确认go文件存在、设置GOROOT、将$GOROOT/bin加入PATH，并在shell配置文件中执行source生效。
go version 命令报错“command not found”怎么办
说明：这不是 Go 没装好，而是 PATH 没配对。Windows/macOS/Linux 都可能卡在这一步，尤其 macOS 和 Linux 用户容易漏掉 source 步骤。
- 检查
go是否真在磁盘上：运行ls /usr/local/go/bin/go（macOS/Linux）或dir C:\Go\bin\go.exe（Windows），确认文件存在 - 确认
GOROOT环境变量是否设置：执行echo $GOROOT（macOS/Linux）或echo %GOROOT%（Windows），若为空，需手动补上，比如export GOROOT=/usr/local/go - 确保
PATH包含$GOROOT/bin而非硬编码路径——万一你把 Go 装到/opt/go却写死/usr/local/go/bin，就必然失败 - 终端重启后配置才生效？错。改完
~/.zshrc或~/.bash_profile后必须手动执行source ~/.zshrc，否则新开终端也读不到
go build 生成的二进制为什么没依赖 libc
Go 默认静态链接全部依赖（包括 runtime、net、crypto 等），所以生成的可执行文件自带运行时，不依赖宿主机的 libc。这是它“一次编译、随处运行”的底层前提。
- 例外情况：当你用
cgo调用 C 代码（比如import "C"），Go 就会动态链接libc，此时go build出来的文件不能直接扔到 Alpine 这类不含 glibc 的镜像里跑 - 强制静态链接（即使用了 cgo）：加
-ldflags '-extldflags "-static"'，但前提是你的 C 代码本身支持静态链接，否则会报cannot use 'static' with 'dlopen' - 验证是否静态：用
ldd your_binary查看输出，如果显示not a dynamic executable，说明是纯静态；若列出一堆libc.so.6，那就是动态链接了
go tool compile 和 go build 的区别在哪
go build 是面向用户的封装命令，go tool compile 是编译器前端的真实入口。日常开发几乎不用后者，但它能帮你定位编译阶段问题。
-
go build main.go会自动处理依赖解析、类型检查、SSA 优化、目标平台适配、链接等全套流程 -
go tool compile -o main.o main.go只做前端工作：词法/语法分析 → AST 构建 → 类型检查 → IR 生成 → SSA 转换 → 生成目标文件（.o），不链接、不打包 runtime - 常见用途：调试编译器行为，比如加
-gcflags="-S"看汇编，本质就是调go tool compile -S；或者用-gcflags="-l"关闭内联，验证性能敏感路径 - 注意：
go tool compile不读go.mod，也不处理 import 路径解析，所有依赖必须已编译成 .a 包或通过-I显式指定路径
为什么 go run 比 go build 快，但不能用于生产
go run 本质是 go build + 立即执行 + 自动清理临时文件。它快是因为跳过了“保存二进制”这步，但代价是每次执行都重新编译，且无法做符号剥离、UPX 压缩等发布优化。
立即学习“go语言免费学习笔记（深入）”；
-
go run编译产物默认放在$GOCACHE下的随机目录，执行完立刻删，没法复用；而go build -o app的输出是确定路径、可审计、可签名的正式制品 - 某些构建标志
go run不支持，比如-buildmode=plugin、-ldflags="-s -w"（虽然能传，但部分 flag 在 run 模式下被忽略） - 最隐蔽的坑：如果你的程序依赖当前目录下的
./config.yaml，go run执行时工作目录是源码所在目录；但用go build生成的二进制，用户可能从任意路径运行它——路径逻辑必须显式处理，不能靠相对路径赌运气
go tool compile -gcflags 系列参数一层层剥开，而不是靠重装 Go 或清缓存解决。 
