因为map和slice底层结构已含指针，值传递时内部指针仍指向同一底层数组或哈希表，故修改元素外部可见；但重赋值（如make）只改副本指针，需用map或[]T才能改变原变量。
为什么传 map 或 slice 通常不用 & 取地址？
因为它们底层结构里已经自带指针：map 变量本质是 *hmap，slice 变量本质是含 array unsafe.Pointer 的结构体。函数传参时虽然拷贝的是这个结构体（值传递），但内部指针仍指向同一块底层数组或哈希表——所以修改元素、增删键值，外部立刻可见。
常见错误现象：
• 写 func modify(m map[string]int) { m["x"] = 1 }，调用后原 map 确实变了；
• 但写 func reset(m map[string]int) { m = make(map[string]int) }，外部 map 不会变——因为只是改了副本里的指针值。
- 需要指针的唯一典型场景：想在函数内重置整个 map（如清空并重新
make）或替换整个 slice（如彻底换底层数组） - 对 nil map/slice 直接操作会 panic，必须先
make初始化，这点和指针的 nil 判定逻辑不同 - 不要为了“看起来像引用”而强行加
*——Go 的设计就是让你少写指针，不是不能写，而是多数时候没必要
slice 的 append 为啥有时不生效？
因为 append 可能触发扩容：当容量不足时，运行时会分配新底层数组，返回一个指向新数组的 slice。原变量仍指向旧数组，内容没变。
示例：func badAppend(s []int) { s = append(s, 99) }
调用后原 slice 长度、内容都不变——除非你返回新 slice 并显式赋值。
立即学习“go语言免费学习笔记（深入）”；
- 要让扩容生效，必须接收返回值：
s = goodAppend(s)，函数定义为func goodAppend(s []int) []int - 如果真想原地修改且允许扩容，就得传
*[]int，但这属于反模式，应优先用返回值风格 - 注意：即使不扩容，
append也不会改变原 slice 的len和cap字段，只改其指向的底层数组内容
map 和 slice 在并发场景下为何都得加锁？
因为它们都不是线程安全的——底层数据结构（hash 表 / 底层数组）被多个 goroutine 共享，但读写操作本身不是原子的。哪怕只是 m[key] = val 或 s[i] = x，也可能在中间被打断，导致 panic 或数据损坏。
- map 并发读写直接 panic：
fatal error: concurrent map writes - slice 并发写同一索引可能丢数据，写不同索引看似安全，但扩容时若多个 goroutine 同时触发，仍可能竞争新数组分配
- 标准解法：用
sync.RWMutex包裹读写，或改用sync.Map（仅适用于读多写少、key 类型受限的场景）
什么时候非得用 *map 或 *[]T？
极少数情况：你需要函数内部完全接管该变量的生命周期，比如重置、释放、或与 C 交互时需传二级指针。
典型例子：
• 清空 map 并复用变量：func clearMap(m *map[string]int) { *m = make(map[string]int) }
• 从 C 分配内存后初始化 slice：C.fillSlice((*C.int)(unsafe.Pointer(&s[0])), C.int(len(s)))
- 日常业务代码中几乎不需要——Go 鼓励“返回新值”而非“就地修改结构体”
- 滥用
*map容易掩盖设计问题：比如本该拆分职责的函数，却靠指针强行耦合状态 - 一旦用了指针，nil 判断就得写成
if m == nil→if *m == nil，多一层间接，也更易漏判
最常被忽略的一点：map 和 slice 的“引用感”是编译器和运行时联手营造的幻觉，它们既不是 Java 的引用，也不是 C 的指针。理解它们的结构体本质（含指针的值类型），比记住“它们是引用类型”有用十倍。
