类型提示不能减少 runtime 错误，但能通过静态检查工具（如 mypy）在编码阶段提前暴露参数类型错误、属性调用错误等问题，从而提升开发效率与代码可靠性。
类型提示真能减少 runtime 错误？
不能直接减少，但能显著提前暴露问题。Python 运行时完全忽略 type hints，它们只在静态检查阶段起作用——比如用 mypy 或 IDE（PyCharm、VS Code + Pylance）做类型推导时。
常见错误现象：传错参数类型（比如把 str 当 int 传给计算函数），或调用不存在的方法（list.append() 写成 list.add()）。这类问题在加了类型提示并运行 mypy 后，往往在编码阶段就被标红，而不是等到测试或上线才抛 AttributeError 或 TypeError。
- 必须配合静态检查工具使用，单独写
def foo(x: str) -> int:不会改变运行行为 -
mypy默认不检查函数体内部，需开启--check-untyped-defs才能覆盖未标注的函数 - 第三方库若没提供 stub（
.pyi文件或内联类型），mypy可能无法准确推断其返回值，导致误报或漏报
什么时候该用 Union、Optional 还是 None？
混淆这三者是新手高频踩坑点。关键区别不在语法，而在语义和工具链响应：
-
Optional[T]等价于Union[T, None]，但更清晰表达“这个值可能为空”——mypy和 IDE 会据此优化补全和空值检查提示 - 直接写
T | None（Python 3.10+）效果相同，但老项目保持Optional[T]更兼容 - 只写
T却实际返回None，mypy会报错；而写成Union[T, str]却只返回T，不会报错，但失去类型精度
示例：def find_user(user_id: int) -> User | None: 比 -> Union[User, None] 更简洁，也比 -> User 更诚实。
立即学习“Python免费学习笔记（深入）”；
泛型类和协议（Protocol）到底解决什么问题？
不是为了炫技，而是应对“鸭子类型”场景下的类型安全。比如你写了个函数处理任意有 .read() 方法的对象，不希望它只接受 io.TextIOBase 子类（太窄），也不愿用 Any（失去检查）。
-
Protocol允许定义结构化接口：class Readable(Protocol): def read(self, size: int = -1) -> str: ... - 任何对象只要实现
read方法，就自动符合该Protocol，无需显式继承 -
Generic[T]主要用于容器类（如Stack[T]），让Stack[int]和Stack[str]在类型检查中互不兼容 - 注意：运行时无法通过
isinstance(obj, Readable)检查Protocol，它纯属静态契约
类型提示会让代码变慢或更难维护吗？
不会影响运行时性能——所有类型注解在编译为字节码时被剥离（除非你主动读取 __annotations__）。但维护成本取决于团队习惯和工具链成熟度。
- 过度嵌套泛型（如
Dict[str, List[Optional[Union[int, float]]]]）可读性差，应改用TypedDict或自定义NamedTuple/dataclass - 动态构造类型（
eval()、getattr()调用带类型的方法）会让静态检查失效，此时需用# type: ignore并附简短说明 - 类型别名（
UserId = NewType("UserId", int)）比直接用int更安全，但需要团队理解NewType不是运行时类型转换
最常被忽略的一点：类型提示本身也是文档。一个函数签名里写着 def load_config(path: Path) -> dict[str, Any]:，比光看函数名和 docstring 更快建立准确预期——尤其当 Path 来自 pathlib，而非字符串路径时。
