Go 写 RESTful API 应避免照搬其他语言习惯：不用嵌套 ServeMux，只用一个顶层 mux；struct 字段须首字母大写并正确加 json tag；POST/PUT 中必须 defer r.Body.Close() 防泄漏。
Go 做 RESTful API 不需要框架也能做对，但错在“照搬其他语言习惯”——比如硬套 Rails 风格的资源路由、滥用中间件堆叠、或把 http.HandlerFunc 当成黑盒反复包装。
用 net/http 写路由时，别写嵌套 http.ServeMux
常见错误是为每个子路径 new 一个 http.ServeMux，再挂到父 mux 上。这会导致路由匹配顺序混乱、404 难排查，且无法统一处理 CORS 或日志。
- 只用一个顶层
http.ServeMux（或直接用http.DefaultServeMux），所有路由注册到它上面 - 路径前缀用字符串拼接，不要靠嵌套 mux 模拟“模块化”，例如：
/api/v1/users直接注册，而非先注册/api再嵌套v1mux - 如果真要分组，用函数封装 handler：定义
func UserHandlers(mux *http.ServeMux)，内部调用mux.HandleFunc(...)，不新建 mux 实例
json.Marshal 返回空对象？检查 struct 字段是否首字母大写 + tag
Go 的 json 包只会序列化导出字段（首字母大写），且默认忽略零值字段。API 返回 {} 或缺失字段，90% 是这个原因。
- 确保 struct 字段首字母大写，例如
ID int `json:"id"`，而不是id int - 用
omitempty要谨慎：CreatedAt time.Time `json:"created_at,omitempty"`在零值时间（如time.Time{}）时会被跳过，可能造成前端解析失败 - 时间字段建议统一用
string类型 +json:"created_at,string"，避免前端时间解析兼容性问题
处理 POST/PUT 请求体时，必须显式调用 r.Body.Close()
漏掉这句会导致连接复用失效、内存泄漏，压测时很快出现 too many open files 错误。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 无论是否成功解析 body，都应在 handler 末尾或 defer 中关闭：
defer r.Body.Close() - 不要在中间件里提前读取整个 body 再塞回
r（Go 的http.Request不支持重放 body），要用io.TeeReader或缓冲到[]byte后重建Request - 推荐用
io.LimitReader(r.Body, 1 限制最大上传体积，防止恶意请求耗尽内存
别用 log.Printf 记录请求，用结构化日志 + 请求 ID 关联
纯文本日志查问题效率极低，尤其并发请求下无法区分哪条 log 属于哪个请求。
- 在 middleware 中生成唯一
X-Request-ID，存入context.Context，所有日志通过ctx.Value()取出并打标 - 用
zap或zerolog替代log包，输出 JSON 日志便于采集（如zap.String("method", r.Method)） - 记录关键点：请求开始、参数解析完成、DB 查询耗时、响应写出前；避免在循环或高频路径中打日志
RESTful 在 Go 里最易被忽视的其实是错误传播链——从 DB 层的 sql.ErrNoRows 到 HTTP 状态码映射，再到 JSON 错误体格式统一，这些细节没串起来，API 表面能跑，实际难维护。
