go version没反应说明path未包含$goroot/bin；需确认shell类型、正确配置path并source，再用which go或where go验证。
go version 命令没反应，说明 PATH 没配对
输入 go version 报 command not found 或直接无响应，不是 Go 没装好，而是系统根本找不到 go 这个可执行文件。关键在 PATH 是否包含 $GOROOT/bin（Windows 是 %GOROOT%\bin）。
常见错误点：
- Linux/macOS 下漏写
export PATH=$GOROOT/bin:$PATH，只写了GOROOT和GOPATH - 改了
.zshrc却用bash启动终端，或改了.bashrc却 shell 是 zsh —— 先运行echo $SHELL确认当前 shell - Windows 上 PATH 里写了
%GOROOT%\bin，但GOROOT变量本身没定义或路径有空格/中文
验证方式：运行 which go（macOS/Linux）或 where go（Windows），没输出就说明 PATH 有问题。
go mod init 后 go list -m all 显示空列表？
这通常不是命令错了，而是项目里没实际 import 第三方包。Go Modules 的依赖树只反映“被显式导入且参与构建”的模块，不是所有下载过的包都会出现在 go list -m all 输出里。
典型场景：
- 刚执行
go mod init example.com/hello，但main.go里只有fmt和os这类标准库 ——go list -m all就只显示你自己的 module，没有第三方依赖 - import 语句写错了，比如
import "github.com/gorilla/mux"拼成"github.com/gorill/mux"，Go 不报错但不会拉取，也不会进依赖树 - 用了 replace 或 exclude 规则，在
go.mod里手动屏蔽了某些模块，它们就不会出现在go list -m all结果中
想看到真实依赖树，至少得有一行有效的第三方 import，并成功 build 过一次（go build 或 go run main.go）。
go get 失败时别硬 retry，先看 GO111MODULE 和代理
go get github.com/sirupsen/logrus 卡住或报 no matching versions，大概率是模块模式没开或代理失效。
检查和修复步骤：
- 运行
go env GO111MODULE，输出必须是on；如果是auto，在 GOPATH 外目录可能不生效，直接设为on：go env -w GO111MODULE=on - 国内用户必须配代理：
go env -w GOPROXY=https://goproxy.cn,direct（比官方proxy.golang.org更稳定） - 如果仍失败，加
-v参数看详细日志：go get -v github.com/sirupsen/logrus，重点关注 “Fetching” 和 “verifying” 阶段卡在哪
注意：go get 在 Go 1.16+ 默认只用于添加依赖，不再推荐用来安装 CLI 工具（如 dlv），该用 go install。
为什么 go mod tidy 会删掉 go.sum 里已有的校验和？
这不是 bug，是 Go Modules 的正常行为：go mod tidy 会清理 go.sum 中“未被当前模块直接或间接依赖”的校验和条目。
触发条件：
- 你删掉了某个 import，但没运行
go mod tidy，go.sum还留着旧记录 - 手动编辑过
go.mod，添加了不存在的 require，之后又撤回 ——go.sum里残留对应 hash - 从别人仓库 clone 项目，对方
go.sum里混入了本地开发时临时引入的模块
安全提示：只要 go.mod 和最终依赖树一致，go.sum 被精简是好事。但上线前务必确认 go mod verify 能通过，否则说明校验和与实际代码不匹配。
环境变量、模块初始化、代理配置、校验和清理——这些环节环环相扣，任何一个断点都会让后续操作失效。最常被忽略的是 shell 配置文件类型和 GO111MODULE 的实际状态，而不是版本号或安装包本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
