直接回答：核心技巧清单：复用 buffer（sync.Pool 或请求级对象携带）、strconv.Append 族替代 fmt.Sprintf（直写 []byte 不经过 interface）、预分配切片容量（make 带 cap 免扩容）、string 与 []byte 零拷贝转换（unsafe.String/unsafe.SliceData，1.20+ 有官方 API）、避免闭包与 interface 装箱逃逸、用小数组替代小 map。验证标准：benchmark 的 allocs/op 为 0。
展开解析：逐项边界：Append 族——strconv.AppendInt(b, v, 10) 这类把结果追加进现有切片，是 strconv 比 fmt 快十倍的主因（无反射无装箱）；string↔[]byte 零拷贝——只适用于明确“转后不再修改”的场景，改了共享底层数组即未定义行为，跨 API 边界慎用；map 替代——key 是整数且范围小，数组索引完胜 map（无哈希无桶溢出）；小对象——结构体返回值而非指针，靠逃逸分析留栈上。体系化思路：分配集中在“每请求一次”的对象上——请求上下文结构携带所有临时 buffer，处理链路全程复用，请求结束整体归还；协议解析类热路径手写解析（unsafe 指针遍历字节）而非 strings.Split 这类制造子串的 API。零分配的边界：别为省分配牺牲正确性——buffer 复用的重置遗漏是脏数据 bug 温床；冷路径零分配是纯炫技；过度 unsafe 转换让代码失去内存安全背书，评审成本上升。判断投入产出：allocs/op 从 10 降到 1 常带来 30%+ 的热路径提速，从 1 到 0 的收益递减——先打大的。
追问方向：写屏障为什么在指针赋值时触发分配之外的代价？unsafe 零拷贝在 GC 视角有何风险？
（约 480 字）