Go中大对象（>32KB）直接走mheap，因跳过mcache/mcentral缓存层，需直连操作系统申请页，导致分配慢、易碎片且释放延迟（闲置超5分钟才归还OS）。
为什么批量任务里切片不预设 cap 就会拖慢吞吐
高频 append 触发底层数组反复 realloc，每次扩容都要拷贝旧数据、申请新内存——在每秒数万条消息的批量推送场景下，这直接抬高 GC 频率和延迟毛刺。更糟的是，如果初始 make([]T, 0)，第一次 append 就得分配，而后续扩容策略（2倍增长）会让内存使用呈阶梯式浪费。
- 实际业务中常见：
batch := make([]Msg, 0)→ 每次append(batch, msg)都可能触发复制 - 正确做法是按预期最大量预设 cap：
batch := make([]Msg, 0, batchSize)，让所有 append 都落在预留空间内 - 注意：cap 不等于 len，
len(batch)是当前元素数，cap(batch)才是底层数组容量，别混淆
sync.Pool 复用对象时最容易漏掉的三件事
sync.Pool 不是银弹，用错反而加重 GC 压力。它只适合固定尺寸、无外部引用、构造开销大的对象；对短命小 struct 或带 map/slice 的结构体硬塞进去，等于白忙活。
- Put 前必须清空可变字段：比如复用
*bytes.Buffer，b.Reset()必须调用，否则下次 Get 出来带着脏数据 - 别把逃逸对象丢进 Pool：如果 struct 字段含指针或接口，
go tool compile -m显示escapes to heap，说明它本就该走堆分配，Pool 只是多一层间接 - Pool 实例生命周期要匹配业务范围：HTTP handler 里 New 一个 struct 再 Put，但 handler 结束后该 struct 还被其他 goroutine 引用，会导致内存泄漏
大对象（>32KB）在批量推送中怎么避免触发 mheap 直接分配
单次分配超 32KB，Go 就绕过 mcache/mcentral，直连 mheap 向 OS 要 page。这种分配慢、易碎片、释放不及时——在日志聚合、protobuf 解析、HTTP body 读取等批量场景极易踩坑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- HTTP body 解析前务必加限长：
http.MaxBytesReader包一层，防恶意请求打爆内存 - 拼接字符串不用
strings.Builder无节制 Grow，改用预分配make([]byte, 0, 16 + <code>append - protobuf 反序列化必须设
SizeLimit，例如proto.UnmarshalOptions{MaxSize: 1 - 关键路径别反复
make([]byte, N)，改用固定尺寸 buffer 池，比如var largeBufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 64
batchProcessor 中计时器重置和容量控制的耦合陷阱
超时 + 数量双触发的批量发送逻辑里，time.Ticker 的重置时机不对，会导致批次延迟失真或空发。这不是并发 bug，而是时间语义理解偏差。
立即学习“go语言免费学习笔记（深入）”；
- 数量触发发送（
len(batch) >= batchSize）→ 必须手动ticker.Reset(timeout)，否则剩余倒计时继续跑 - 超时触发发送（
select { case ）→ 不用 Reset，Ticker 自动续期，这是新周期起点 - 输入 channel 关闭且
len(batch) > 0→ 发完立即 return，不 Reset，也不再启动新 ticker - batchSize 和 timeout 要监控实际值：
batch_size_actual和batch_latency_ms，别只看配置；压测时观察下游 429 错误拐点，动态调低 batchSize 比硬扛更稳
