能，但需区分 nil map 和空 map；len(m)==0 对非 nil map 安全高效，而 nil map 虽 len 为 0 却不可写，正确判断应为 m != nil && len(m) == 0。
Go 中 len() 能不能直接判断 map 是否为空
能，但前提是 map 不是 nil。对非 nil 的 map，len(m) == 0 是安全且高效的空判断方式；但如果 m 是 nil，len(m) 依然合法、返回 0 —— 这容易让人误以为“nil map 就是空 map”，其实二者语义不同：nil map 不能写入，空 map 可以。
常见错误现象：
• 程序 panic 在 m["key"] = value，报 assignment to entry in nil map
• 单元测试里用 assert.Equal(t, len(m), 0) 通过了，但后续写操作崩溃
- 使用场景：适合已知 map 已初始化（比如函数参数明确要求非
nil，或刚用make(map[string]int)创建） - 性能影响：
len()是 O(1)，无额外开销 - 注意：
len()对nilmap 返回 0，不 panic，这点和 slice 不同（slice 的len(nil)也合法）
为什么不能只靠 len(m) == 0 判断“可安全写入”的空状态
因为 nil map 和空 map 都满足 len(m) == 0，但只有后者支持赋值。你需要区分“逻辑上空”和“未初始化”两种情况。
典型踩坑点：
• 把函数返回的 map[string]int 直接当可写容器用，没检查是否为 nil
• JSON 反序列化时字段为 null，Go 解出来是 nil map，不是空 map
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：同时检查
m != nil和len(m) == 0，例如：if m != nil && len(m) == 0 { ... } - 如果目标只是“能否写入”，直接判
nil更本质：if m == nil { m = make(map[string]int) } - 标准库中如
encoding/json解析null到 map 字段，结果就是nil，不是make(...)出来的空 map
如何安全地初始化或复用 map 避免 nil 写 panic
最稳妥的方式，是在任何可能写入前确保 map 已初始化。别依赖调用方传入非 nil 值，尤其涉及外部输入（API、配置、JSON）时。
- 函数入口防御：在函数开头加
if m == nil { m = make(map[string]int) } - 结构体字段初始化：在 struct 定义时用指针或初始化方法，避免零值为
nil；或者在UnmarshalJSON里重写UnmarshalJSON方法，把null转成空 map - 使用
sync.Map？注意：sync.Map的零值是可用的，但它是为并发读多写少设计的，普通场景用原生 map + 显式初始化更清晰 - 不要用
reflect.ValueOf(m).IsNil()—— 多余，m == nil就够了
对比：map、slice、channel 的 nil 行为差异
Go 里这三者都允许 nil，但行为不一致，容易混淆。
-
map：len(nil)返回 0，for range nil不 panic（安静跳过），但写操作 panic -
slice：len(nil)返回 0，for range nil同样安静跳过，append(nil, x)合法，返回新 slice -
channel：len(nil)panic，select在nilchannel 上永远阻塞，close(nil)panic
所以别凭经验跨类型套用判断逻辑。map 的“可读不可写”特性，是它最常被误用的一点。
