类型注解仅在静态分析阶段生效，需配合mypy等工具检查；Python运行时完全忽略，错误类型如int写成str也不会报错；必须用--follow-imports控制第三方包检查，用TYPE_CHECKING避免循环依赖，3.10+支持T|None替代Optional[T]，__future__ import annotations可延迟解析注解。
类型注解不会自动校验，不加 mypy 就等于没写
Python 运行时完全忽略类型注解，str 注解写成 int 也不会报错。它只在静态分析阶段起作用，而 Python 解释器本身不执行任何检查。
常见错误现象：def greet(name: int) -> str: return f"Hello {name}" 能正常运行，哪怕传入字符串；IDE 可能标黄，但脚本照样跑通——这容易让人误以为“类型写了就安全了”。
- 必须配合
mypy（或pyright、pylance）做独立检查 -
mypy默认不递归检查第三方包，--follow-imports=normal或--follow-imports=skip要按需选 - 用
typing.TYPE_CHECKING做条件导入，避免运行时循环依赖
Optional[T] 和 T | None 在 Python 3.10+ 是等价的，但旧版本只能用前者
写 Union[T, None] 或 Optional[T] 是为了表达“可能为 None”，但 Python 3.10 引入了更简洁的 T | None 语法。两者语义一致，但兼容性差异明显。
使用场景：函数返回值、字典 get() 结果、可选参数默认值为 None 时。
立即学习“Python免费学习笔记（深入）”；
- Python from typing import Optional +
Optional[str] - Python ≥ 3.10：推荐
str | None，更直观，且和mypy兼容良好 - 混用会导致
mypy报Incompatible types，尤其在泛型嵌套时（如Dict[str, Optional[int]]vsDict[str, int | None]）
过度注解反而降低可维护性，特别是动态结构和鸭子类型场景
给每个变量、返回值、参数都硬套类型，看似严谨，实则增加修改成本。比如处理 JSON 返回、**kwargs、getattr() 动态属性时，强行标注会逼你用 Any 或复杂 TypedDict，反而掩盖真实意图。
性能影响为零（注解不参与运行），但维护负担真实存在：改一个字段名，可能要同步更新七八处类型声明。
- 优先注解公共接口（函数签名）、核心数据模型（
dataclass、NamedTuple） - 对
dict类型，用Dict[str, Any]不如明确建TypedDict；但若结构频繁变动，先用Any比写一堆过期注解强 -
cast()和TYPE_CHECKING是必要的逃生舱口，别怕用
__future__.annotations 让注解延迟求值，解决前向引用和循环导入
类内部引用自身类型（如 def copy(self) -> MyClass:）或两个模块互相注解时，不加处理会直接报 NameError 或 mypy 报错。
Python 3.7+ 支持 from __future__ import annotations，把所有注解转成字符串，推迟到真正需要时（如 get_type_hints()）再解析。
- 必须放在文件最顶部（在 docstring 之后、其他 import 之前）
- 启用后，
__annotations__的值是字符串而非实际类型对象，影响反射逻辑 - 搭配
typing.get_origin()和typing.get_args()才能安全提取真实类型
mypy 能提前拦住 AttributeError 时，那种“改完代码立刻知道哪里漏了”的确定感，才是它真正落地的地方。 
