mallocgc 是 go 运行时内存分配的统一入口，所有堆对象分配均由此处理，小对象走 mcache，大对象直连 mheap，逃逸分析决定栈/堆分配，与框架无关。
mallocgc 是 Go 运行时内存分配的统一入口，所有堆上对象的分配最终都会走到这里。它不区分框架或业务代码——Gin、Echo、gRPC 里的结构体、切片、map，只要逃逸到堆，就由这套机制处理。框架本身不实现内存分配器，只是触发它的使用条件。
逃逸分析决定变量去哪，不是框架决定的
框架代码里返回一个 *http.Request 或构造一个 map[string]interface{}，是否分配在堆上，完全取决于编译器的逃逸分析结果，跟框架无关。
常见误判点：
- 以为 “用了 Gin 就一定堆分配” —— 实际上
c.Param("id")返回的是string（栈上拷贝），而c.BindJSON(&v)中的&v才可能逃逸（取决于v是否被闭包捕获或返回） - 在中间件里对
context.WithValue传入大结构体指针，直接导致该结构体逃逸到堆，且生命周期延长至整个请求链 - 框架封装的
json.Marshal调用，如果传入的是局部变量地址（如&user），且该变量未被其他 goroutine 引用，通常不会逃逸；但若传入的是闭包捕获的变量，则大概率逃逸
mallocgc 怎么选内存路径：小对象走 mcache，大对象直连 mheap
Go 的分配器按对象大小自动路由：
- 小于等于 16B 且无指针：走
tiny allocator，合并分配，避免碎片 - 16B ~ 32KB：查
mcache.alloc[spanClass]，命中则无锁返回；未命中则向对应mcentral加锁申请新mspan，再填回mcache - 大于 32KB：跳过缓存，直接调
largeAlloc向mheap申请连续 page，按需向操作系统mmap
注意：spanClass 不是对象大小，而是向上取整后的规格编号（例如 48B 对象 → class 4 → bytes/obj=48）。查看具体映射可用 go tool compile -gcflags="-m" main.go 输出中的 size class: 行。
框架高频操作容易引发隐式逃逸
以下模式在 Web 框架中很常见，但容易被忽略其堆开销：
-
log.Printf("req: %+v", r)：格式化时反射遍历*http.Request字段，触发大量临时字符串和切片分配，全部堆上 - 中间件中
bytes.Buffer或strings.Builder作为局部变量使用没问题，但若将其地址存入context或返回给 handler，则整个缓冲区逃逸 - Gin 的
c.ShouldBindJSON(&v)内部会 new 一个json.Decoder，该 decoder 包含缓冲区和状态机，必然堆分配；但v本身是否逃逸，仍看其定义位置和引用范围
调试逃逸和分配路径的真实手段
别靠猜，用工具定位：
- 看逃逸：加
-gcflags="-m -l"编译，输出里出现... moved to heap或... escapes to heap的行就是关键线索 - 看分配路径：运行时开启
GODEBUG=gctrace=1,maphint=1，可观察scvg（scavenger）行为和 span 分配统计 - 压测时用
pprof的allocsprofile：go tool pprof http://localhost:6060/debug/pprof/allocs，聚焦 top allocators，常暴露框架封装层下的真实分配热点
真正难的不是理解三级缓存结构，而是识别哪些看似 innocuous 的框架调用，悄悄把本可栈分配的小对象推到了堆上——尤其是跨函数边界的值传递和反射使用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
