接口设计应从 e.GET() 和 c.JSON() 边界入手，结构体字段需大写加 json:"name" tag，路由注册后必须调用 e.Start() 或 e.StartServer()，并显式启用 middleware.Recover() 捕获 panic，否则线上静默失联。
接口设计不是先画UML再写代码，而是从 e.GET() 和 c.JSON() 的边界开始——错一个 json:"name" tag、漏一次 e.Start()、没加 middleware.Recover()，线上就静默失联。
为什么 c.JSON() 返回空对象或 404？检查结构体导出性与路由注册时机
空对象不是数据没传进去，是字段根本没被序列化出来；404 不是路由没写，是服务根本没真正启动。
-
name string这种小写字段永远进不了 JSON，必须大写 + 显式json:"name"tag -
e.GET("/user/:id", handler)写完不调e.Start(":8080")，netstat 看似监听成功，但 curl 会一直 pending - 用自定义
http.Server时，必须走e.StartServer(server)，直接server.ListenAndServe()绕过 Echo 路由链，所有路由失效 - 路径参数
c.Param("id")为空？确认请求 URL 和注册路径完全一致：大小写、尾部斜杠、正则约束（如/user/:id([0-9]+)）缺一不可
panic 导致接口静默崩溃？必须显式启用 middleware.Recover()
Echo 不像 Gin，默认不捕获 panic。一个未处理的 panic 就会让 goroutine 直接退出，HTTP 连接挂起，日志可能只有一行 stack trace，前端收不到任何响应。
- 必须在
main()里加e.Use(middleware.Recover())，这是上线前必检项 -
e.HTTPErrorHandler只处理 Echo 自身错误（比如c.String()失败），不接管 runtime panic - 如果用了自定义
http.Server，还要确保server.ErrorLog配置到位，否则 panic 日志可能被丢弃 - 中间件里调外部 HTTP 或 DB 时，别让超时/连接失败触发 panic；优先用
if err != nil分支返回c.JSON(500, ...)
高频接口性能卡点在哪？避免 new 大结构体 + 善用 sync.Pool
高并发下 GC 压力和内存分配是隐形瓶颈，c.JSON() 内部虽有对象池，但开发者仍容易在 handler 里反复 new DTO 或 buffer。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 对 QPS > 1k 的接口，把常用 DTO 实例或 JSON 序列化 buffer 放进
sync.Pool复用 - 别用
map[string]interface{}构造响应体，结构体 +json:"field"tag 更快且类型安全 - 大文件下载或流式响应，用
c.Stream()+io.Copy()，避免全量加载到内存 - 数据库/Redis 连接池大小别设成 100，一般按
CPU 核数 × 2 ~ 5配，过大反而争抢连接锁
如何让错误响应统一且可 debug？自定义 HTTPErrorHandler + 结构化日志
默认 panic 恢复后返回的是 HTML 错误页，不适合 API 场景；而简单 return error 又丢失上下文，排查时只能靠猜。
- 设置
e.HTTPErrorHandler = func(c echo.Context, err error) { c.JSON(500, map[string]string{"error": err.Error()}) }，至少保证格式统一 - 真实项目中，用
zerolog替代log.Printf，在 error handler 里记录req_id、path、status、duration - 不要在中间件里用
fmt.Printf同步打日志，它会阻塞 goroutine；zerolog的WriteSyncer才是生产可用方案 - 鉴权失败、参数校验失败等业务错误，别混在 panic 里处理；用
echo.NewHTTPError(401, "invalid token")主动抛出，方便统一拦截
最危险的坑往往藏在“跑起来了”的假象里：端口监听了、路由注册了、handler 也写了——但少一个 middleware.Recover()，或结构体字段忘了大写，线上流量一上来就失联，日志里连错误痕迹都难抓。
