空引用为何危险：Null Reference 的问题与移除代价
副标题 / 摘要 空引用（null reference）是许多语言里最常见、最隐蔽的错误来源。本文解释它的问题根源，并讨论如果从语言层面移除 null，工程上会发生哪些变化。 目标读者 在日常开发中经常遇到 NPE 的工程师 关注类型系统与语言设计的中级开发者 需要制定团队空值规范的技术负责人 背景 / 动机 空引用让“缺失”变成一个运行时炸弹：它绕过了编译期检查，把错误延后到线上。 Tony Hoare 将 null 称为 “Billion-Dollar Mistake”，并不夸张，因为这类错误难复现、难定位、损失巨大。 核心概念 Null Reference：指向“无对象”的引用值 可空类型（Nullable）：类型系统中显式标注“可能不存在” Option/Maybe：用代数数据类型表达“有值 / 无值” Null Object：用默认对象代替 null，消除分支 实践指南 / 步骤 边界处标注可空：DB/JSON/外部 API 都可能产生缺失字段。 优先使用 Option/Maybe：让“可能缺失”变成类型的一部分。 可空值进入核心域之前要处理：转换成默认值或显式错误。 开启静态检查：例如 TypeScript strictNullChecks。 必要时用 Null Object：减少分支，保持业务逻辑纯净。 示例配置（TypeScript）： { "compilerOptions": { "strictNullChecks": true } } 可运行示例 下面用 Null Object 消除空引用： class User: def __init__(self, name: str): self.name = name def greeting(self) -> str: return f"Hello, {self.name}" class NullUser(User): def __init__(self): super().__init__("Guest") def greeting(self) -> str: return "Hello, Guest" def find_user(user_id: int) -> User: if user_id == 1: return User("Alice") return NullUser() if __name__ == "__main__": print(find_user(1).greeting()) print(find_user(404).greeting()) 解释与原理 空引用的问题不在“值为 null”，而在它把“业务状态”变成了“控制流”。 一旦你忘记判断，就会在运行期炸裂。 移除 null 的语言（如 Rust、Haskell）强迫你在类型层面处理缺失情况，换来更强的可维护性与可测试性。 ...