go新手易在接口设计和错误处理上出错，因未理解“显式优于隐式”哲学：error必须手动返回和检查，不可滥用panic；any/interface{}应限于泛型或工具函数，业务中滥用将丢失编译期类型安全；goroutine泄漏常源于select使用不当。
Go 语言新手最容易在接口设计和错误处理上栽跟头，不是语法不会，而是没理解它“显式优于隐式”的底层哲学。
为什么 error 必须手动返回、不能 panic 到处甩
新手常把 panic 当成 Python 的 raise 用，结果一上线就触发服务级崩溃。Go 的 error 是值，不是控制流——它被设计成必须被看见、被处理、被传递。
- HTTP handler 里
json.Unmarshal失败，别panic，要return err或写入http.Error - 数据库查询失败时，
rows.Err()和rows.Next()返回的error都得分别检查，漏一个就可能静默丢数据 - 自定义错误建议用
fmt.Errorf("failed to parse %s: %w", input, err)包裹，保留原始调用链，别用+ " failed"拼接
interface{} 和 any 看似自由，实则埋雷最多
Go 1.18 引入 any 后，很多人以为可以放心当万能类型用了。但实际中，它几乎只该出现在泛型约束或极简工具函数里；业务逻辑里滥用 any 或 interface{}，等于主动放弃编译期类型检查。
- 接收 JSON 数据时，别用
map[string]interface{}解析嵌套结构，优先定义 struct（哪怕字段是json.RawMessage） - 函数参数如果是
any，调用方大概率传错类型，而编译器不报错——运行时才 panic - 需要动态字段？考虑用
map[string]json.RawMessage+ 显式json.Unmarshal，比一路.(map[string]interface{})类型断言安全得多
goroutine 泄漏比内存泄漏更难发现，且往往源于 select 写法不当
新手写并发最爱套模板：for { select { case ，但只要 <code>ch 关闭后没退出循环，goroutine 就永远卡在 select 里等永远不会来的消息。
- 所有带
select的无限循环，必须有明确退出路径：要么加default分支做心跳，要么监听ctx.Done()，要么在case 后判断 <code>ch是否已关闭 - 用
sync.WaitGroup等待 goroutine 结束时，Done()必须在 defer 里调用，否则 panic 会导致计数器漏减 - 测试并发代码时，别只测“功能对”，加一行
runtime.NumGoroutine()对比前后值，能快速暴露泄漏
Go 的简洁是有代价的：它把很多“默认行为”砍掉了，比如自动资源回收、异常传播、运行时反射类型推导。你写的每行代码，几乎都在直面系统真实行为。这点最开始难受，但一旦适应，debug 时会少翻 80% 的文档。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
