6.4 常用标准库与扩展库选型地图
6.4 常用标准库与扩展库选型地图
本节摘要：Go 标准库的覆盖面足以让多数服务"零第三方依赖起步"：strings 与 bytes 的文本处理、time 的时刻与时长、io 的 Reader/Writer 抽象体系、encoding 族的 JSON 等编解码、net/http 的服务端与客户端、log/slog 的结构化日志。本节按任务给出选型地图，并标注哪些场景该引入哪些成熟的第三方库。
你能学到什么
阅读完本节，你应当能够：
- 按任务快速定位正确的标准库包；
- 用 io 的接口体系组合数据流；
- 掌握 JSON 编解码的标签定制与常见坑；
- 说出 net/http 服务端与客户端的最小用法；
- 知道何时引入第三方库、引哪些经过生态检验的。
一、选型地图：按任务找包
| 任务 | 标准库包 | 备注 |
|---|---|---|
| 字符串处理 | strings | 查找、切分、拼接、变换 |
| 字节切片处理 | bytes | 接口同 strings，操作字节 |
| 格式化输入输出 | fmt | 打印、扫描、错误构造 |
| 时间 | time | 时刻、时长、定时器、格式化 |
| 数学与随机 | math、math/rand | 复数复用 math/cmplx |
| IO 抽象 | io、bufio | Reader、Writer、缓冲 |
| 文件与目录 | os、path/filepath | 跨平台路径处理 |
| JSON | encoding/json | 标签驱动映射 |
| HTTP | net/http | 服务端客户端一体 |
| 模板 | text/template、html/template | 后者自动转义防注入 |
| 结构化日志 | log/slog | 键值对日志 |
| 同步与并发 | sync、sync/atomic、context | 第 5 章全讲过 |
两条使用哲学先立住：标准库优先——同一件事官方实现经过最长期的生产检验与安全审计；够用再引第三方——依赖是负债，每次引入都要用"省下的时间"偿还。
二、io 体系：一切数据流的通用插座
标准库最深的设计是 io.Reader 与 io.Writer 两个单方法接口（第 3 章提过）。文件、网络连接、压缩流、加密流、内存缓冲全部实现这两个接口，于是任何读源都能接任何写端：
src, _ := os.Open("in.txt") dst, _ := os.Create("out.txt") n, _ := io.Copy(dst, src) // 通用搬运：不关心两端是什么
io.Copy 是"数据搬家"的万能胶水；bufio 的读写缓冲包装让裸 IO 提速；strings 的 Reader 把字符串变成流。理解了这对接口，一半标准库的 API 面目就统一了：它们都是插座之间的转接头。
三、JSON：标签驱动的编解码
type Movie struct { Title string `json:"title"` Year int `json:"year,omitempty"` // 零值时省略 Artist string `json:"-"` // 永不输出 } m := Movie{Title: "流浪地球", Year: 2019} data, _ := json.Marshal(m) // 编码 var m2 Movie json.Unmarshal(data, &m2) // 解码：传指针！
编解码基于反射（呼应 6.1：字段遍历加标签读取正是反射的主场）。三个高频坑：Unmarshal 忘传指针报错；大小写字段匹配是大小写不敏感的宽匹配，标签才是精确控制；未知字段默认忽略（宽松模式），需要严格校验时用解码器开严格选项。大文件流式处理用 Decoder 逐个读值，别把整个文件读进内存再解析。
四、net/http：服务端客户端一体
服务端三行起步（第 4.1 节见过雏形），工程化的核心是中间件模式——一个"包一层的处理函数"：
func withLogging(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { start := time.Now() next.ServeHTTP(w, r) log.Printf("%s 耗时 %v", r.URL.Path, time.Since(start)) }) }
鉴权、日志、限流、恢复（兜住 panic 转 500，呼应第 2 章）全部以这种"洋葱圈"叠加。客户端同样内建：一个 Client 类型发请求，超时设置是必答题（默认无超时的客户端在生产上是事故预约）。每个请求还应把 ctx 挂上（第 5.5 节的取消传播终点就在这）。
⚠️ 常见坑：HTTP 客户端响应体不关闭——连接无法复用，高并发下句柄耗尽。规矩：拿到响应体，立刻 defer 关闭，读完为止。
五、第三方库：什么时候、引什么
判断顺序：标准库有没有 → 半官方扩展库（golang.org/x 系，如更全的加密、终端控制）有没有 → 最后才看社区。社区库的检验标准三条：维护活跃度、破环性变更历史、传递依赖数量。
几个生态里久经考验的方向（具体选型以当期评估为准）：SQL 数据库访问走标准的数据库接口加对应驱动；Web 路由增强与 Redis、消息队列等中间件客户端各有主流实现；配置、依赖注入、断言测试辅助也有成熟工具链。原则不变：能被两行标准库替代的，不引一个框架。
图：依赖决策流
六、读文档的习惯
标准库的官方文档每页自带可运行的示例（正是 6.3 节示例函数的产出），看包先扫示例再读接口列表，效率高一截。遇到"这个功能标准库在哪"的问题，按本节选型地图的"任务列"反查即可。
💡 关键直觉：标准库是自家厨房——干净、稳定、随时可用；第三方库是外卖——快，但每单都要看评分（维护与依赖）。
七、io 接口体系图
问答补遗。时间处理要注意什么？ 时区——时间类型的构造与格式化显式带地点，服务器与用户时区不一致是经典事故；时长用类型常量表达可读性最好。日志选 log 还是 slog？ 新项目直接结构化日志（键值对），机器可解析、可检索；老 log 包留给小程序快速打印。标准库版本演进要跟吗？ 语义化版本下小版本升级成本低，定期升到最新补丁版是安全卫生；大特性（如泛型）按需引入。
本节速览
- 选型地图：文本 strings、时间 time、流 io、JSON encoding、HTTP net/http、日志 slog。
- io 双接口是数据流的世界语，Copy 是万能搬运工。
- JSON 标签定制：改名、omitempty、连字符排除；Unmarshal 传指针，大文件用 Decoder 流式。
- 中间件洋葱圈是 HTTP 工程化的组织范式；客户端超时与响应体关闭是两条保命规矩。
- 依赖四道闸：标准库、x 库、自写、社区库，逐级放宽。
- 示例即文档，看包先看示例。
下一节收尾：工具链全景。