go函数参数均为值传递，slice、map、chan等“引用类型”实为含指针字段的结构体值；传参拷贝结构体而非底层数据，故append需接收返回值，map/chan内容可直接修改。
Go 函数参数永远是值传递，包括 slice、map、chan、interface
Go 没有引用传递，只有值传递。所谓“引用类型”是误导性说法——slice、map、chan、*T、interface{} 这些类型变量本身仍是值，只是它们的底层数据结构包含指针字段。传参时拷贝的是这个结构体（比如 slice 是 3 字段：ptr、len、cap），不是底层数组。
常见错误现象：append 后原 slice 长度没变、map 修改在函数外不可见——其实不是“没生效”，而是你没把返回值接住，或误以为修改了传入变量本身。
- 对
slice做append后必须接收返回值：s = append(s, x)，否则扩容后新底层数组地址丢失 -
map和chan可直接修改内容（如m["k"] = v、ch ），因为结构体里的指针字段被拷贝了，仍指向同一块内存 -
interface{}传参时会拷贝其内部的 type 和 value；如果 value 是大结构体，又没用指针，就会触发完整拷贝
struct 传参要不要加 *？看大小和是否要修改
struct 是纯值类型，传参即拷贝全部字段。小 struct（如 type Point struct{ X, Y int }）拷贝开销小，按值传更安全、更符合 Go 的 immutability 直觉；大 struct（比如含 []byte 或嵌套 map）按值传可能引发意外性能问题，且无法原地修改。
使用场景：time.Time 是 struct，但设计为不可变，所以所有方法都返回新实例；而 bytes.Buffer 虽也是 struct，但大量方法接收 *Buffer，因为它需要修改内部 buf []byte。
立即学习“go语言免费学习笔记（深入）”；
- 若 struct 小于 2–3 个机器字长（通常 ≤16 字节），按值传没问题
- 若需在函数内修改字段并让调用方看到，必须传
*T - 若 struct 包含 slice/map/chan/interface，即使小，也要注意：这些字段内部指针被拷贝，但 struct 本身仍是副本
interface{} 接收任意类型时，底层值怎么拷贝？
interface{} 是两字宽结构体：一个指向类型信息的指针 + 一个指向值的指针（或直接存小值）。传参时拷贝这个两字宽结构体，不拷贝实际数据——但关键点在于“小值”的判定。
常见错误现象：往 map[interface{}]interface{} 存一个大 struct，以为只存指针，结果内存暴涨——因为 struct 值被完整复制进 interface 的 data 字段（未逃逸到堆）。
- 小于 16 字节（如
int64、[2]int32）可能直接存 inline，不分配堆内存 - 大于 16 字节或含指针字段的 struct，会分配堆内存，interface 存的是该堆地址
- 传
*T给interface{}，只拷贝指针（8 字节），最省
sync.Map 为什么不能用普通 map 的思维理解？
sync.Map 不是线程安全版 map，它是为“读多写少 + key 生命周期长”场景优化的特殊结构。它内部用 read/write 两层 map + mutex 分离读写路径，但代价是：不支持遍历、不保证迭代一致性、删除后 key 不立即从 read map 清除。
容易踩的坑：sync.Map.LoadOrStore 返回的 bool 表示“是否发生了存储”，不是“是否已存在”；Range 回调中修改 map 会导致 panic；用 sync.Map 存临时对象（如 HTTP 请求上下文）反而比普通 map + mutex 更慢、更占内存。
- 高频写（如每秒万级更新）、key 动态生成 → 用
map+sync.RWMutex - 配置缓存、连接池等长期存活 key →
sync.Map才有意义 - 不要用
sync.Map替代map[string]*T做对象池，它的 GC 友好性不如手动管理
事情说清了就结束。真正难的不是记住“值传递”，而是每次写函数前下意识问一句：我传进去的东西，底层数组/堆内存/指针字段，到底被拷贝了几份？
