go command not found 是 path 未生效而非安装失败；unreachable code 是编译错误，因 return/panic 后存在不可达代码；panic 是运行时崩溃，需依堆栈定位 nil 解引用等；error 为 nil 却异常，多因忽略 err != nil 检查。
go 命令报 command not found，说明 Go 二进制没进 PATH，不是安装失败，而是路径没生效。先确认你到底想解决哪一类问题——是环境跑不起来、编译过不了，还是运行时 panic 崩溃？不同阶段的报错，排查逻辑完全不同。
go command not found：PATH 没生效，不是没装好
Windows 上常见于 MSI 安装时勾选了 “Add to PATH”，但没重启终端；Linux/macOS 则多因 shell 配置文件漏写 export PATH=$PATH:/usr/local/go/bin（macOS Homebrew 默认路径）或 export PATH=$PATH:/root/go/go/bin（Linux 手动解压路径）。
- 验证方法：运行
echo $PATH，看输出里有没有 Go 的bin目录 - 别用
sudo su切换后测试——那是 root 环境，和你日常用户无关 - Windows 路径含空格（如
C:\Program Files\Go）时，某些旧 shell 会解析失败，建议重装到C:\Go - macOS 用 Homebrew 安装后，若用 zsh 却没初始化
brew shellenv，需手动加eval "$(brew shellenv)"
unreachable code：编译器明确告诉你代码走不到
这不是警告，是编译错误，意味着某段代码在任何执行路径下都不可达。最常见三种情况：
-
return、panic、os.Exit后面紧跟其他语句，比如return 1; fmt.Println("dead") - 条件恒为真/假，比如
if true { ... }或for true { ... }后面还有语句 - 所有
case分支都以return或panic结尾，但switch后面还写了代码
修复很简单：删掉不可达部分，或把逻辑提前到 return 前。Go 不允许“写出来但永远不执行”的代码。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
panic: runtime error：运行时崩溃，得看堆栈定位位置
这类错误不会在编译时报出，一运行就崩，典型信息如 nil pointer dereference、index out of range、concurrent map read and map write。关键不是背错误类型，而是学会读第一行和 goroutine 堆栈：
-
nil pointer dereference：检查变量是否为nil再解引用，尤其结构体指针、接口、切片头指针 -
index out of range：访问数组/切片/字符串前，先用len()校验，别信外部输入 -
concurrent map read and map write：内置map不是并发安全的，改用sync.Map、加sync.RWMutex，或通过 channel 协调读写 - 注意 panic 发生在哪个 goroutine —— 主 goroutine 崩溃容易发现，子 goroutine 崩溃可能静默退出，得靠日志或
recover捕获（仅限 defer 中）
error 值为 nil 却行为异常：忽略了错误返回值本身
Go 的错误是显式返回的 error 类型，不是抛异常。很多问题其实不是“报错”，而是你没检查 err != nil 就继续用了返回值。
- 例如
os.Open失败返回nil文件句柄 + 非nil错误，但你直接对file调用Read，就会 panic - 函数签名带
(T, error)，必须每个分支都返回，漏写会导致编译失败或零值误用 - 用
errors.Is或errors.As判断具体错误类型，别只用err == nil做粗粒度判断 - 别在循环里累积错误却不处理，比如批量写文件时只记最后一个
err，前面的失败就被吞了
真正难的不是看懂错误信息，而是意识到：Go 把“错误是否发生”交给你自己检查，而不是替你决定要不要中断流程。这点一旦忽略，问题就会藏得很深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
