应避免handler中频繁堆分配大结构体或切片，优先使用栈分配、sync.pool复用小对象，禁用map[string]interface{}序列化，改用预定义struct和json.rawmessage，日志和中间件需异步化，流式响应应绕过内存全量加载。
避免 handler 中频繁 new 大结构体
高频接口里每次请求都 new User{} 或 make([]byte, 1024)，会直接抬高堆分配速率，触发更频繁的 GC。Echo 的 c.JSON() 虽然内部用了对象池，但你传进去的 struct 实例如果每次都新建，池就起不到作用。
- 对固定大小的 DTO 或 buffer，用
sync.Pool预先注册构造函数，Get()/Put()复用 - 小结构体（如仅含 2–3 个字段）优先用栈分配：直接声明
u := User{...}，避免取地址后逃逸 - 用
go build -gcflags="-m -m"检查关键变量是否逃逸；若出现... escapes to heap，就得重构
JSON 序列化时别用 map[string]interface{}
用 map 动态拼 JSON 看似灵活，但每次调用 json.Marshal() 都要反射遍历键值、动态分配内存，比 struct tag 方式慢 3–5 倍，且无法复用序列化 buffer。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 定义明确的响应 struct，用
json:"id,omitempty"控制字段输出 - 避免在 handler 里做
map[string]interface{}{"data": u, "code": 200}这类包装——提前定义type Resp struct { Code int `json:"code"` Data interface{} `json:"data"` } - 若需运行时字段控制，考虑用
json.RawMessage缓存已序列化的字节片段
中间件和日志别拖慢请求路径
一个同步写磁盘的日志中间件，在 QPS 5000 时可能让 P99 延迟从 5ms 拉到 80ms —— 它不是“慢”，而是阻塞了整个 goroutine。
- 禁用
fmt.Printf、log.Println等同步 I/O 日志；改用zerolog或zap的异步写入模式 - 鉴权、统计类中间件，把耗时操作（如 HTTP 调用、DB 查询）移到 goroutine 或缓存中，主流程只做校验
- 不要在中间件里调
c.Request().Body读全文——它不可重复读，后续 handler 可能 panic；改用c.Request().Context()传递预处理结果
流式响应时绕过内存全量加载
返回大文件或长连接 SSE 时，若用 c.String(string(data)) 或 c.JSON(resp)，整个 payload 会先被序列化进内存，再 flush。10MB 文件 × 100 并发 = 至少 1GB 内存瞬时占用。
- 用
c.Stream()+io.Copy()直接转发 Reader，例如io.Copy(c.Response(), file) - 对生成式响应（如 CSV 流），用
bufio.Writer包裹c.Response().Writer，手动控制 flush 时机 - 注意设置
Content-Length或使用Transfer-Encoding: chunked，否则客户端可能卡住等待 EOF
make([]byte, ...) 在每秒万次请求下正疯狂喂饱 GC。逃逸分析和 pprof heap profile 必须成为上线前的常规动作，而不是出问题后再补救。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
