1. 为什么需要Union和Optional类型提示
刚开始用Python写代码时，我总觉得动态类型真方便——想传什么就传什么。直到有次凌晨三点调试一个bug，发现函数里把字符串当数字计算，才明白类型提示的重要性。Python的typing模块就像给代码装上GPS，而Union和Optional就是其中最常用的两个路标。
想象你在写一个处理用户数据的函数。用户年龄可能是整数（25）、浮点数（25.5）或者字符串（"25"）。这时候Union就派上用场了：
from typing import Union def parse_age(age: Union[int, float, str]) -> int: return int(float(age))而Optional更适合那些"可有可无"的参数。比如用户选填的个人简介：
from typing import Optional def save_profile(name: str, bio: Optional[str] = None): if bio is None: print(f"{name}没有填写个人简介") else: print(f"{name}的简介：{bio}")实际项目中，我见过太多因为混淆这两者导致的bug。有个同事用Union[str, None]代替Optional[str]，虽然功能相同，但可读性差了一大截。就像用螺丝刀开红酒——能行，但不优雅。
2. Union的实战应用场景
2.1 处理多种输入类型
上周我重构一个旧项目时遇到典型场景：有个计算面积的函数，最初只支持整数输入。后来需求变更，要支持浮点数，再后来还要支持字符串数字。用Union可以完美应对：
from typing import Union Number = Union[int, float, str] def calculate_area(length: Number, width: Number) -> float: return float(length) * float(width)这里我定义了一个类型别名Number，代码顿时清晰很多。Pylance插件还能基于这个提示，在传入非法类型（如字典）时给出警告。
2.2 联合自定义类型
在开发Web应用时，经常需要处理多种返回类型。比如这个API响应处理器：
from dataclasses import dataclass from typing import Union @dataclass class Success: data: dict code: int = 200 @dataclass class Failure: error: str code: int = 500 ApiResponse = Union[Success, Failure] def process_response(response: ApiResponse) -> None: if isinstance(response, Success): save_to_db(response.data) else: log_error(response.error)这种用法在FastAPI等框架中极为常见。通过联合自定义类型，代码既安全又易于维护。
3. Optional的正确打开方式
3.1 可选函数参数
新手最容易犯的错误是把所有可能为None的参数都用Union表示。其实Optional是更语义化的选择。比如这个查找函数：
from typing import Optional def find_user(user_id: int, include_details: Optional[bool] = None) -> dict: user = get_from_db(user_id) if include_details: user["details"] = get_details(user_id) return userinclude_details参数有三种状态：
- 不传（默认None）
- 传True
- 传False
用Optional[bool]比Union[bool, None]更准确地表达了设计意图。
3.2 数据库字段处理
处理数据库记录时，Optional简直是救命稻草。比如用户表的中间名字段：
from typing import Optional class User: def __init__( self, first_name: str, last_name: str, middle_name: Optional[str] = None ): self.first_name = first_name self.last_name = last_name self.middle_name = middle_name这样ORM框架能正确生成可为NULL的字段。我在Django项目里忘记用Optional，结果迁移文件总是报错，折腾了半天才发现问题。
4. 常见坑点与性能优化
4.1 不要过度使用Union
有次代码审查，我看到这样的类型提示：
Union[int, float, str, bool, list, dict]这基本等于没加类型提示！当Union超过3种类型时，就该考虑重构了。比如用抽象基类或Protocol：
from typing import Protocol class SupportsArea(Protocol): def calculate_area(self) -> float: ... def print_area(shape: SupportsArea) -> None: print(shape.calculate_area())4.2 Optional的性能影响
在性能敏感的代码中，Optional会带来轻微开销。比如这个热点函数：
from typing import Optional def process_data(data: Optional[list] = None) -> list: data = data or [] return [x*2 for x in data]每次调用都要做None检查。如果确定参数必须传入，去掉Optional性能会更好：
def process_data(data: list) -> list: return [x*2 for x in data]在微秒级的优化场景下，这种差别会累积成可观的开销。我的经验是：先保证正确性，再考虑性能优化。
5. 类型检查工具实战
5.1 mypy配置技巧
在pyproject.toml中配置mypy，可以让Union和Optional检查更严格：
[tool.mypy] strict_optional = true disallow_any_unimported = true warn_redundant_casts = true这样写Optional[int]时，mypy会强制检查None处理逻辑。有次提交代码前mypy报错，发现漏处理了一个Optional返回值，避免了一个线上bug。
5.2 PyCharm的智能提示
PyCharm对typing的支持非常智能。比如这段代码：
from typing import Optional def get_config() -> Optional[dict]: ... config = get_config()输入config.时，PyCharm会提示"dict可能有None"，并建议先做None检查。这个功能帮我节省了大量调试时间。
6. 新版Python的改进
Python 3.10引入了更简洁的写法：
# 旧写法 from typing import Union, Optional x: Union[int, str] y: Optional[int] # 新写法 x: int | str y: int | None但在兼容旧版本的库中，我仍然建议使用typing模块的写法。等3.10成为最低版本要求后，新语法确实能让代码更清爽。
在大型项目中合理使用Union和Optional，能让代码像乐高积木一样严丝合缝。刚开始可能觉得麻烦，但习惯后会发现它们其实是提高开发效率的利器。最近我在团队推行严格的类型检查后，运行时错误减少了近40%，这大概就是类型提示的魅力所在吧。
