maps.clone 是浅拷贝，新建 map 并逐个赋值键值对，修改副本不影响原 map；但 value 为 slice 或指针时内容仍共享，非深拷贝。
maps.Clone 是浅拷贝，但和赋值行为不同
直接写 m2 := m1 是 header 复制，m2 和 m1 共享底层哈希表；而 maps.Clone(m1) 会新建一个 map，并逐个 k, v 赋值进去，所以修改 m2 不会影响 m1。这不是“深拷贝”（value 是 slice 或指针时内容仍共享），但已足够隔离键值对层级的修改。
- 并发场景下必须用
maps.Clone，否则多个 goroutine 写同一 map header 可能 panic - 传 map 给函数前想保留原 map 不被意外修改，优先
maps.Clone而非直接传参 - 如果 value 是
[]byte或*struct{}，maps.Clone后改其内容仍会影响原 map —— 这是预期行为，不是 bug
maps.Keys 返回切片，顺序不可靠
maps.Keys 底层就是 for range 收集 key，而 Go 的 map 遍历从 1.10 起就固定为伪随机起始点，每次运行顺序都可能不同。它不提供排序保证，也不打算提供。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
maps.Keys(m)[0]去取“第一个键”，结果不确定 - 需要稳定顺序时，必须显式排序：
keys := maps.Keys(m); sort.Strings(keys) - 做存在性检查（如
maps.Contains(m, k)）或批量处理（如遍历所有 key 发请求）完全没问题，顺序无关
maps.DeleteFunc 不会 realloc，但会改变 len()
maps.DeleteFunc(m, fn) 是就地删除：它遍历原 map，对满足条件的键调用 delete(m, k)。不会新建 map，也不会提前预估容量，所以底层数组没变，只是标记部分 bucket 为空。
- 删除后
len(m)准确反映剩余键数，但内存占用不会立即下降 - 如果反复增删导致碎片多，可后续用
maps.Clone(m)触发紧凑重建 - 函数内不能对
m做新增操作（比如在fn里往m写新 key），会导致 panic 或未定义行为
maps.Equal 要求 key/value 类型都 comparable
maps.Equal(m1, m2) 内部用 == 比较每个 key 和 value，所以两个 map 的 key 类型、value 类型都必须满足 Go 的可比较约束（不能是 slice、map、func、包含它们的 struct）。
- 若 value 是
[]int，直接用maps.Equal会编译失败，得换maps.EqualFunc+ 自定义比较逻辑 - key 是自定义 struct 时，确保所有字段都可比较，否则
maps.Equal无法通过类型检查 - 空 map 之间恒等：
maps.Equal(map[string]int{}, map[string]int{}) == true
maps.Keys(nil) 或 maps.Clone(nil) 都会 panic。所有 maps 函数都不处理 nil，必须自己先 if m == nil { ... }。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
