Scala mutable.Map的put/get方法处理null的行为不符合预期？

这个问题确实戳中了Scala可变集合在Java兼容性和自身设计原则之间的一个小矛盾点——毕竟Scala一直倡导用Option来替代null，避免空指针，但可变Map的这个行为确实有点反直觉。

先确认你遇到的现象是真实存在的，你的代码示例完全能复现这个问题：

import scala.collection.mutable
val m: mutable.Map[String, String] = mutable.Map.empty
m.put("Bogus", null) // 返回 Option[String] = None
m.get("Bogus") // 返回 Option[String] = Some(null)

为什么会出现这种情况？ #

Scala的可变集合（比如mutable.HashMap）底层其实是对Java集合的包装，而Java的HashMap允许存储null值。为了和Java代码无缝交互，Scala没有强行禁止可变Map存入null，这就导致了和Scala自身设计理念的冲突——Option本来是用None表示“值不存在”，Some表示“存在有效值”，但这里Some(null)把null当成了一个合法的“存在的值”，后续如果直接调用res1.get就会触发NullPointerException，完全违背了用Option避免空指针的初衷。

怎么解决这个问题？ #

这里有几个不同场景下的处理方案：

• 优先使用不可变Map：Scala的不可变Map（scala.collection.immutable.Map）会在你尝试存入null值时直接抛出异常，从源头杜绝这种问题，这也是Scala推荐的使用方式。
• 给可变Map加非空校验：如果因为和Java交互必须用可变Map，建议封装一个安全的put方法，提前拦截null值：

def safePut[A, B](map: mutable.Map[A, B], key: A, value: B): Option[B] = {
  if (value == null) throw new IllegalArgumentException("Null values are not allowed in this map")
  else map.put(key, value)
}

• 获取值时转换Some(null)为None：如果已经存在存入null的情况，可以在获取值时额外处理，把不符合预期的Some(null)转换成None：

m.get("Bogus").flatMap(Option(_)) // 这样得到的就是 None 而不是 Some(null)

内容的提问来源于stack exchange，提问作者hiroprotagonist