本文介绍如何通过自定义函数实现类型守卫，使静态类型检查器（如 mypy、PyCharm）能正确推断 Optional[T] 值在断言后已非 None，从而消除类型错误，并对比 assert 与显式异常的适用场景。
本文介绍如何通过自定义函数实现类型守卫，使静态类型检查器（如 mypy、pycharm）能正确推断 `optional[t]` 值在断言后已非 none，从而消除类型错误，并对比 `assert` 与显式异常的适用场景。
在 Python 类型提示实践中，我们常遇到 Optional[T]（即 T | None）类型的变量，需在使用前确认其非 None。虽然运行时可用 assert val is not None 确保安全，但仅靠 assert 并不能让类型检查器“理解”后续代码中该值已确定为 T 类型——除非配合类型守卫（Type Guard）或类型细化（type narrowing）机制。
✅ 正确的类型守卫函数签名
要让类型检查器识别 not_none() 的返回值不再是 T | None，而是确定的 T，需将参数声明为 T | None，并返回 T：
from typing import TypeVar, TypeGuard
T = TypeVar("T")
def not_none(val: T | None, msg: str) -> T:
assert val is not None, msg
return val? 关键点：
- 使用 val is not None（而非 assert val），避免对 bool、0、"" 等 falsy 值误判；
- 返回类型标注为 T（而非 T | None），向类型检查器明确传达“此函数成功返回即意味着输入非 None”；
- TypeVar("T") 保证泛型推导准确（例如传入 str | None，返回即为 str）。
⚠️ 注意：assert 不适用于生产环境的空值防护
Python 的 assert 在启用优化模式（python -O）时会被完全移除，此时 not_none() 将失去运行时保护作用。因此，该版本仅推荐用于开发调试或绝对可信的内部断言场景（例如单元测试中已确保前置条件成立）。
立即学习“Python免费学习笔记（深入）”；
若需在生产环境中强制保障非空逻辑，请改用显式异常：
def not_none(val: T | None, msg: str) -> T:
if val is None:
raise ValueError(msg) # 或 TypeError，根据语义选择
return val该写法既保留类型守卫效果（静态检查器仍能推断返回为 T），又具备可靠的运行时校验能力。
? 类型检查器原生支持：无需额外函数（推荐优先尝试）
现代主流类型检查器（mypy ≥ 0.930、Pyright、PyCharm 2022.3+）均支持 类型细化（Type Narrowing）。这意味着你往往根本不需要 not_none() 函数：
from typing import Optional x: Optional[int] = get_data() # x += 1 # ❌ 错误：int | None 不支持 += 操作 assert x is not None # ✅ 类型检查器 now knows: x is int x += 1 # ✅ 通过类型检查
同理，if x is not None:、while x is not None: 等控制流语句也能触发类型细化。因此，在多数场景下，优先使用原生 assert x is not None 或 if 分支，比封装函数更简洁、更符合 Python 类型生态惯例。
✅ 总结建议
| 场景 | 推荐方案 |
|---|---|
| 快速验证 + 开发调试 | assert x is not None（配合类型细化） |
| 需复用逻辑且接受运行时风险 | not_none(x, "x required")（assert 版） |
| 生产级健壮性要求 | not_none(x, "x required")（raise 版）或直接 if x is None: raise ... |
| 团队协作/可读性优先 | 避免过度封装，善用 assert / if 触发类型细化 |
最终，类型守卫的本质是向类型系统提供精确的控制流语义。与其依赖自定义函数，不如深入理解类型细化规则——它更轻量、更标准，也更少引入抽象泄漏。
