go中&和操作的是类型安全的引用而非裸地址，&x是否导致堆分配由逃逸分析决定，与显式取址无直接因果关系；t变量本身占固定大小，其存储位置与指向位置无关。
Go 中 & 和 * 到底在操作什么内存
Go 的指针不是 C 那种裸地址，而是类型安全的引用。当你写 &x，编译器会判断 x 是否可寻址（比如不能对 123 或 func(){}() 取地址），再决定是否把它分配在堆还是栈上——这步完全由编译器逃逸分析决定，和你写不写 & 没有直接因果关系。
常见误解是“用了指针就一定在堆上”，其实：
- 小结构体传值开销低，编译器可能仍选择栈分配，即使你传了 *T
- 大结构体或生命周期超出当前函数的变量，即使没显式取地址，也可能被自动移到堆上
- 用
go build -gcflags="-m -m"看逃逸分析结果，重点关注moved to heap和escapes to heap - 避免无意义取地址：比如
return &SomeSmallStruct{}，不如直接返回值，减少间接访问开销 -
*T类型变量本身（即指针值）仍占固定大小（通常是 8 字节），它存在哪（栈 or 寄存器）和它指向哪（堆 or 栈）是两回事
什么时候该用指针接收者，什么时候不该
指针接收者主要解决两个问题：修改原值、避免大对象拷贝。但别一上来就全用指针——这反而可能阻碍逃逸分析，把本可在栈上的东西推到堆上。
- 如果方法需要修改 receiver，必须用指针接收者（
func (t *T) Mutate()） - 如果
T是大结构体（比如字段总 size > 几十个字节），且方法只读，也建议用指针接收者减少复制成本 - 如果
T是小结构体（如type Point struct{ x, y int }）、基础类型（int、string）或sync.Mutex这类含不可拷贝字段的类型，值接收者更合适；尤其是sync.Mutex，用指针接收者是强制要求，因为它的零值是有效状态，拷贝会导致未定义行为 - 接口实现一致性：如果某个方法用了指针接收者，那所有方法最好都用指针接收者，否则容易出现 “
T实现了接口，但*T没有” 或反过来的混淆
new、make 和字面量初始化的区别与误用
new(T) 返回 *T，内存全零初始化，适用于任意类型；make([]T, n) 或 make(map[K]V) 返回的是非指针类型（切片/映射/通道），且只支持这三种内置引用类型；字面量（如 []int{1,2,3}）则按需分配并初始化。
- 别用
new([]int)：它返回*[]int（指向切片头的指针），几乎没用；应该用make([]int, 0)或字面量 -
make(map[int]string)创建的是可直接使用的 map；而new(map[int]string)返回的是*map[int]string，其值为nil，解引用后仍是nilmap，写入 panic - 切片字面量
[]byte("hello")底层数据在只读段，不能修改；若需可变，用make([]byte, 5)或append([]byte{}, "hello"...) - 小数组（如
[4]int）用字面量最高效；大数组尽量避免，考虑切片 +make
sync.Pool 适合缓存什么，又为什么常被误用
sync.Pool 不是通用对象池，它是为“临时、高频、大小稳定”的对象设计的，比如 bytes.Buffer、[]byte 切片、JSON 解析中间结构体。它不保证对象复用，GC 会清理未使用的对象，也不适合持有长生命周期或带外部资源（如文件句柄）的对象。
立即学习“go语言免费学习笔记（深入）”；
- 池中对象应在
Put前重置状态（如b.Reset()、b = b[:0]），否则下次Get可能拿到脏数据 - 不要把
sync.Pool当作减少 GC 压力的万能药：如果对象分配频率不高，或对象大小波动大，池反而增加管理开销 - 避免在
init()中预热池——sync.Pool本身是惰性初始化的，且预热对象可能在第一次 GC 时就被回收 - 观察
runtime.ReadMemStats中的PauseNs和NumGC，比盲目加 Pool 更可靠
真正影响内存效率的，往往不是某一行 & 或 make，而是结构体字段布局、切片预估容量、以及是否让无关数据意外逃逸到堆上——这些细节在压测时才容易暴露出来。
