这八个包是日常开发中真正高频、不可绕过的标准库，覆盖输入输出、字符串处理、类型转换、文件/系统交互、网络通信、数据序列化、时间控制和协程生命周期管理。
fmt、strings、strconv、os、net/http、encoding/json、time、context 这八个是日常开发中真正高频、不可绕过的标准库。其他如 sync、database/sql、log 属于“按需启用”，而像 io、bufio 多数时候是配合主库隐式使用。
为什么不是“全列出来”，而是这八个？
Go 标准库有 100+ 包，但绝大多数项目里，80% 的逻辑只依赖这八个——它们覆盖了输入输出、字符串处理、类型转换、文件/系统交互、网络通信、数据序列化、时间控制和协程生命周期管理。其余包要么场景极窄（如 expvar），要么已被更高层封装替代（如直接用 os.ReadFile 而非 os.Open+io.ReadFull）。
os 和 io 怎么选？小文件 vs 大文件
新手常误以为 os.Open + io.ReadAll 是万能读法，结果在读取几百 MB 日志时 OOM。
- 小文件（os.ReadFile("./config.json")，简洁安全，自动关闭
- 大文件或流式处理：必须用
os.Open+bufio.Scanner按行读，或io.Copy流式转发 - 写文件同理：
os.WriteFile适合配置写入；追加日志要用os.OpenFile(..., os.O_APPEND)配合fmt.Fprintf
net/http 的陷阱：不关响应体、不设超时、不传 context
这是线上服务最常引发连接泄漏和 goroutine 泄漏的三连错。
立即学习“go语言免费学习笔记（深入）”；
- 客户端请求后，
resp.Body必须defer resp.Body.Close()，否则底层 TCP 连接不会释放 - 不用默认
http.DefaultClient，要自定义并设置Timeout：&http.Client{Timeout: 5 * time.Second} - HTTP 调用（尤其下游依赖）必须传
ctx：req.WithContext(ctx)，否则上游 cancel 无法中断下游请求
encoding/json 解析失败却不报错？检查字段导出性和 tag
常见现象：json.Unmarshal 返回 nil 错误，但结构体字段仍是零值——大概率是字段未导出或 tag 写错。
- 结构体字段名必须首字母大写（即导出），否则 JSON 包无法反射赋值
- tag 中的 key 名要和 JSON 字段严格一致（区分大小写），比如
`json:"user_id"`对应{"user_id": 123}，写成`json:"userId"`就失效 - 嵌套结构体或切片字段，记得初始化（如
Items []Item不需要 new，但 map 要map[string]T{}）
真正难的不是记住这些库的名字，而是每次写 http.Get 时下意识补上 defer resp.Body.Close()，每次解 JSON 前瞄一眼字段是否大写，每次打开文件前想清楚“它有多大”。标准库不藏技巧，只藏习惯。
