new(T)只分配内存不初始化，&T{}触发字段初始化且支持选择性赋值；sync.Pool对象需手动重置，方法集影响重用方式；逃逸分析以“escapes to heap”为准。
为什么 new 和 &T{} 行为看起来一样但本质不同
它们都返回指向新分配零值的指针，但底层语义不同：new(T) 只分配内存、不调用构造逻辑；&T{} 是复合字面量取地址，会触发字段初始化（哪怕只是零值），且支持字段选择性赋值。
常见错误是误以为 new(Struct) 会执行任何方法或初始化函数——它不会。比如定义了 func NewX() *X 构造函数，直接用 new(X) 就绕过了它，可能留下未校验的字段状态。
实操建议：
- 除非明确需要“纯零值裸指针”，否则优先用
&T{}或封装好的构造函数 - 如果结构体有非零默认字段（如
sync.Mutex），必须用&T{}或构造函数，new(T)会导致该字段为零值（sync.Mutex零值虽可用，但语义上易误导） - 在性能敏感路径（如高频对象池）中，
new略轻量，但差异微乎其微，别过早优化
对象池 sync.Pool 重用时最常踩的坑
sync.Pool 不保证对象一定被重用，也不保证只重用一次；它只提供“尽力而为”的缓存机制。典型错误是假设从 Get() 拿到的对象是干净的——其实可能是上次用完没清空的脏数据。
使用场景集中在短生命周期、高分配频率的对象，比如临时切片、解析器上下文、HTTP header map。
实操建议：
- 每次
Get()后必须手动重置字段，不能依赖零值，例如：v := pool.Get().(*Buffer); v.Reset() -
Put()前确保对象不再被其他 goroutine 使用，否则引发 data race；尤其注意闭包捕获或 channel 发送后仍持有引用 - 避免放入含 finalizer 或依赖 GC 清理的资源（如文件句柄），
Pool不触发 finalizer - 测试时禁用 GC（
GOGC=off）可放大重用行为，便于验证清理逻辑是否健壮
方法集与指针接收者如何影响对象重用判断
一个类型 T 的方法集包含所有值接收者方法；*T 的方法集包含值接收者 + 指针接收者方法。这直接影响你能否把某个变量传给期望 *T 的函数，进而决定是否必须取地址或能否复用已有指针。
常见错误是定义了指针接收者方法（如 func (x *T) Do()），却试图对值类型变量调用：t.Do() 编译失败，而 (&t).Do() 才合法——这意味着你不得不创建新指针，破坏了原地重用意图。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 若类型需频繁重用且暴露修改方法，统一用指针接收者，并始终传递
*T，避免值拷贝和隐式取址 - 若类型小（
uintptr大小以内）、只读、无指针接收者方法，用值类型更自然，也利于逃逸分析优化 - 混用值/指针接收者会导致方法集分裂，比如
interface{Do()}可能无法满足，检查时用go vet或 IDE 提示
逃逸分析怎么看？go build -gcflags="-m" 输出里哪些行真关键
真正决定对象是否堆分配的是逃逸分析结果，不是有没有用 new 或 &。关键看编译器输出中是否出现 “moved to heap” 或 “escapes to heap”。
容易被忽略的是：即使变量声明为局部，只要它的地址被返回、传入闭包、或存入全局 map/slice，就必然逃逸。
实操建议：
- 逐级加
-m：先-m，再-m -m（显示更详细原因），最后-m -m -l（禁用内联辅助诊断） - 重点关注形如 “
&vescapes to heap” 的行，它告诉你哪个变量的地址泄漏了 - 避免在循环内反复
new同一结构体并 append 到切片——切片底层数组本身可能逃逸，导致所有元素一起堆分配 - 用
go tool compile -S看汇编，确认是否有call runtime.newobject调用，这是堆分配的铁证
立即学习“go语言免费学习笔记（深入）”；
实际写业务代码时，指针和重用的复杂点不在语法，而在生命周期管理：谁负责清空、谁负责释放、谁持有最终所有权。这些细节一旦错位，轻则内存浪费，重则数据污染或 panic。多跑几遍go run -gcflags="-m" *.go，比读十遍文档更管用。 
