Go中map传参是值传递，但修改key-value生效是因为map结构体头含指向底层hmap的指针，副本指针仍指向同一内存；重赋值map变量（如m=nil）只改形参指针字段，不影响外层。
Go 中传 map 到函数里，改 key-value 会直接生效，但重赋值整个 map 变量（比如 m = nil 或 m = make(map[string]int)）不会影响外层变量——这是值传递指针的典型表现，不是“引用传递”，也不是“真引用”。
为什么修改 map 元素能穿透函数边界？
因为 map 变量本身是一个结构体头，内部包含指向底层 hmap 的指针。函数参数接收的是这个结构体头的副本，但副本里的指针仍指向同一块底层哈希表。所以 m["key"] = "val"、delete(m, "key") 这类操作都作用于共享内存。
-
make(map[string]int)返回的是*hmap类型指针，不是纯值 - 函数内打印
fmt.Printf("%p", m)和外层地址一致，说明指针值被复制了 - 这和
slice行为一致，但和struct、int完全不同
哪些操作对外部 map 无效？
所有试图替换整个 map 变量的操作，只会改掉函数栈帧里那个结构体头的指针字段，不影响调用方持有的原始结构体头。
-
m = nil：只让形参m指向空，原变量仍持有旧hmap地址 -
m = make(map[string]int)：新建一个hmap，但只更新了形参的指针字段 -
m = anotherMap：同理，只是复制另一个结构体头，不改变调用方的内存布局
什么时候必须传 *map[K]V？
极少数需要重置或替换整个 map 实例时才用指针，比如初始化校验失败后清空并重建，或在多 goroutine 竞态中需原子替换 map 实例。
- 常见误用：
func loadConfig(m *map[string]string)→ 实际只需func loadConfig(m map[string]string)，除非你要执行*m = parseNewMap() - 正确场景示例：
func resetMap(m *map[int]string) { *m = make(map[int]string) } - 性能上无优势：传
*map多一次解引用，且违背 Go 惯用法
nil map 调用写入会 panic
如果传入的是未初始化的 nil map，函数内任何写操作（m[k] = v）都会触发 panic: assignment to entry in nil map，这不是传递问题，而是底层 hmap 为空指针。
- 安全做法：函数开头加
if m == nil { m = make(map[string]int) }，但注意这只是局部修复，不影响外层nil - 更健壮方式：调用方确保 map 已初始化，或函数设计为返回新 map（
func buildMap() map[string]int） - 切记：判断
m == nil是合法的，但len(m)、range m在nilmap 上也安全，唯独写入不行
真正容易被忽略的点是：你看到的“引用效果”完全依赖底层指针的共享，一旦脱离这个前提（比如重赋值、传 nil），行为就立刻回归纯值传递逻辑。别被 fmt.Println 输出迷惑，要盯住指针值是否被覆盖。
