应坚持用标准库net/http：启动轻量服务、健康检查、简单代理或爬虫时，其无中间件抽象、错误路径清晰、调试直接、二进制体积小，且路由注册和客户端配置更直白可控。
标准库优先，第三方包只在标准库明显缺位时引入。 Go 的设计哲学是“自带电池”，绝大多数场景用 fmt、net/http、encoding/json、os、strings 这几个包就能闭环，强行上第三方反而增加维护成本和安全风险。
什么时候该坚持用标准库的 net/http 而不是 gin 或 echo
你只需要启动一个轻量 HTTP 服务、写个健康检查接口、做简单代理或爬虫，net/http 就够了。它没有中间件抽象、不隐藏连接生命周期、错误路径清晰——调试时你能直接看到 http.Server 启动失败是因为端口被占，而不是被框架某层封装吞掉的 timeout 错误。
- HTTP 客户端场景下，
http.DefaultClient配合context.WithTimeout已满足 90% 的请求需求 - 服务端注册路由用
http.HandleFunc，比写router.GET("/path", handler)少一层间接性 - 自定义
http.RoundTripper做重试或日志时，标准库结构更直白，不用猜框架哪一层拦截了 Transport - 如果项目里只有 2–3 个接口，引入
gin会多出约 1.2MB 的二进制体积（含反射、模板等未使用代码）
encoding/json 解析失败时，为什么 json.Unmarshal 返回 json.SyntaxError 却没告诉你具体哪一行
因为 json.Unmarshal 默认不开启行号追踪，它只在解析失败时返回一个带偏移量（Offset）的错误，而不会主动计算行号。你得自己按字节偏移去源数据里定位。
- 实际报错类似：
invalid character '}' looking for beginning of object key string (offset 42) - 要快速定位，可先用
json.Compact清理空格，再用bytes.IndexByte手动统计换行符数量 - 生产环境建议加一层包装：读取 JSON 前先用
json.Valid快速校验，避免 Unmarshal 后才 panic - 若必须精确行号（如配置文件校验），改用
json.Decoder并设置DisallowUnknownFields()，它在部分错误路径中能提供更细粒度上下文
字符串拼接选 strings.Builder 还是 fmt.Sprintf？
取决于拼接频率和内容稳定性。fmt.Sprintf 简单场景够用，但每次调用都分配新字符串；strings.Builder 是零拷贝拼接，适合循环内高频追加或构建大文本。
- 拼接次数 ≤ 3 次、变量少且类型固定，用
fmt.Sprintf("key=%s,value=%d", k, v)更直观 - 循环中拼接日志行、生成 CSV 或 HTML 片段，必须用
strings.Builder，否则 GC 压力陡增 -
strings.Builder的Grow方法值得预设容量，比如已知最终长度约 2KB，就调b.Grow(2048)，避免多次扩容复制 - 注意：
strings.Builder.String()返回的是拷贝，后续修改 Builder 不影响已返回字符串；而builder.Reset()可复用内存，别漏掉
真正容易被忽略的是：标准库包之间的边界其实很薄。比如 os.Open 返回的 *os.File 同时实现了 io.Reader 和 io.Writer，你可以直接把它传给 json.NewDecoder 或 bufio.NewReader，不需要任何转换函数——这种隐式兼容性才是标准库高效协作的关键，不是靠文档记住每个包怎么用，而是理解它们共享的接口契约。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
