Go中错误必须显式检查，忽略会导致panic或静默失败；Context须作为首参传递并设超时防泄漏；JSON响应应使用json.Encoder而非字符串拼接。
错误变量未检查导致 panic 或静默失败
Go 框架中绝大多数 I/O、数据库、HTTP、JSON 解析等操作都返回 error，忽略它几乎必然引发后续问题——要么 panic（如解包 nil map），要么返回空/零值误导调用方。
- 常见写法：
json.Unmarshal(body, &data)后不检查err，结果data是零值但程序继续执行 - 真实场景：Gin 中
c.ShouldBindJSON(&req)失败却没处理，req字段全为零，后续逻辑误判为合法请求 - 修正方式：必须显式判断，且避免只打日志就放行；业务关键路径建议直接
return或用c.AbortWithError() - 注意：
if err != nil后忘记return是高频失误，尤其在中间件或 handler 多分支时
Context 未传递或超时未设导致 goroutine 泄漏
框架（如 Gin、Echo）的 handler 默认接收 context.Context，但很多开发者仍用全局变量或硬编码超时，造成长连接堆积、内存泄漏。
- 典型错误：
http.Client调用未传ctx，或用了context.Background()却没设超时 - 后果：上游请求已断开，下游 HTTP 调用仍在等待，goroutine 卡住不释放
- 正确做法：从
c.Request.Context()（Gin）或r.Context()（net/http）获取并传递；必须用context.WithTimeout()或WithCancel() - 额外提醒：
defer cancel()要紧随WithTimeout之后，否则可能在 handler 返回前就被调用
JSON 响应未用 Encoder 导致格式错误或截断
直接用 fmt.Fprintf(w, "%s", jsonStr) 或拼接字符串返回 JSON，极易出错：缺少 Content-Type、转义失效、中文乱码、响应被截断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 现象：
invalid character '（浏览器 HTML 替代页被当 JSON 解析） - 根本原因：没设
w.Header().Set("Content-Type", "application/json; charset=utf-8")，且fmt不做 JSON 转义 - 标准解法：用
json.NewEncoder(w).Encode(data)—— 它自动设 header、处理转义、支持流式编码 - 注意：
Encode()末尾自动加换行，若需紧凑输出可 wrapbytes.Buffer后写入w
中间件顺序错乱或未调用 next 导致链中断
中间件本质是函数链，漏掉 next(c)（Gin）或 next.ServeHTTP()（net/http）会让请求卡死，而顺序颠倒（如鉴权在日志后）则破坏语义。
立即学习“go语言免费学习笔记（深入）”；
- Gin 典型错误：自定义中间件里忘记
c.Next()，所有后续 handler 都不执行 - Mux 错误：用
router.Use()注册中间件时，顺序与预期相反（先注册的先执行） - 调试技巧：在中间件开头打日志，确认是否进入；在
c.Next()前后分别打时间戳，看是否卡住 - 安全边界：鉴权类中间件必须在最前，panic 捕获类必须在最后，否则无法兜底
if err != nil 的写法，每次 context 的传递深度，以及每个中间件里那行看似微不足道的 c.Next()。 
