编译错误在go build阶段即被拦截，运行时错误则发生在程序启动后。前者如未定义变量、类型不匹配；后者如panic、nil指针解引用、channel操作错误，需通过go run或执行二进制文件触发。
编译错误：代码根本过不了 go build
Go 是静态编译语言，go build 阶段就严格检查语法、类型、符号引用。只要出现拼写错误、未声明变量、类型不匹配、导入未使用、函数签名不符，就直接报错退出，压根不会生成可执行文件。
常见现象包括：undefined: xxx（变量/函数没定义）、cannot use xxx (type xxx) as type xxx（类型强转失败）、imported and not used（导入包但没用）、syntax error: unexpected xxx（少括号、逗号或换行误用）。
关键点在于：这类错误和运行环境无关，Windows/macOS/Linux 上表现一致；修复后必须重新 go build 才能继续。
- 别在
main()里写fmt.Println(unexistVar)就跑 —— 编译器当场拦下 - 接口实现检查是编译期做的：
type T struct{}没实现io.Writer的Write方法，赋值给io.Writer变量就会报错 -
go vet和golint不是编译器一部分，它们不阻止构建，但建议在 CI 中前置运行
运行时错误：程序启动了，但中途 panic 或崩溃
运行时错误发生在二进制已生成、进程已启动之后，典型代表是 panic 和非空 error 值。它们不会让 go build 失败，但会让程序非正常终止或逻辑出错。
立即学习“go语言免费学习笔记（深入）”；
最常触发的有：panic: runtime error: index out of range（切片越界）、panic: runtime error: invalid memory address or nil pointer dereference（nil 指针解引用）、panic: send on closed channel（向已关闭 channel 发送）。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
注意：Go 不把 panic 当作“异常”来设计，它不支持 try/catch；recover 只能在 defer 中捕获同 goroutine 的 panic，且不能恢复已崩溃的 goroutine 状态。
- 空指针不是编译错误：如果
var s *string，然后直接fmt.Println(*s)，编译通过，运行时 panic -
error值本身不是错误，只是约定返回的错误信号；漏判if err != nil是逻辑 bug，编译器不管 - 并发场景下，
data race不会触发 panic，但会导致不可预测行为；需用go run -race单独检测
哪些错误既可能编译期暴露，也可能运行时才浮现？
有些问题边界模糊，是否报错取决于上下文。比如类型断言、反射调用、JSON 解析 —— 编译器只管语法和接口兼容性，具体值是否合法得等运行时才知道。
例如：v, ok := interface{}(42).(string) 编译通过，但 ok 为 false；而 v := interface{}(42).(string)（不带 ok）会在运行时 panic。
-
json.Unmarshal([]byte(`{"name":123}`), &struct{name string})编译没问题，但运行时因类型不匹配静默忽略字段，或返回json.UnmarshalTypeError -
reflect.Value.MethodByName("Foo").Call([]reflect.Value{})编译通过，但若方法不存在或不可导出，运行时 panic -
unsafe.Pointer相关操作完全绕过编译检查，后果自负
调试时怎么快速区分是编译错还是运行错？
看终端第一行输出。如果命令卡在 go build、go run 或 go test 阶段并打印红色错误信息，就是编译错误；如果看到可执行文件路径、进程 PID，或者输出了一部分日志再崩，就是运行时错误。
容易混淆的是：有些编辑器（如 VS Code）默认开启保存即 build，看起来像“改完代码自动报错”，其实仍是编译阶段拦截。而 go run main.go 是先编译再立即运行，所以它报的错可能是编译错，也可能是运行错 —— 关键看错误前有没有成功打出 binary 路径。
- 运行
go build -o ./tmp.bin .成功 → 编译没问题；再执行./tmp.bin崩溃 → 运行时问题 -
panic: assignment to entry in nil map这类错误一定出现在运行时，因为 map 声明（var m map[string]int）本身合法，只有第一次m["k"] = v才触发 panic - IDE 的波浪线提示大多来自
gopls，它模拟编译检查，但可能滞后或误报；以命令行go build结果为准
error 值 —— 它们安静地穿过所有函数，直到某个地方突然 nil 或数据错乱，你还以为是上游传参的问题。 
