Python 3.12 的类型提示本身不影響運行時性能，因注解默認不求值；from __future__ import annotations 仍必要以避免前向引用錯誤、確保延遲解析及兼容反射操作；get_type_hints() 是性能敏感點，需緩存結果；PEP 695 泛型為編譯期語法糖，無額外運行時開銷。
Python 3.12 的类型提示本身不会影响运行时性能——类型注解在默认情况下根本不会被求值，更不会执行任何逻辑。所谓“影响性能”，几乎全是误读或配置不当导致的副作用。
为什么 from __future__ import annotations 在 Python 3.12 仍有必要
Python 3.12 默认启用了 PEP 563 的行为（即所有注解都以字符串字面量形式存储），但这个行为仅对新语法有效；旧代码若含未加引号的前向引用（如 def f() -> MyClass:，而 MyClass 尚未定义），仍会在模块导入时触发 NameError。
所以即使在 3.12 中，你仍需显式写 from __future__ import annotations 来确保：
- 所有注解统一延迟到需要时（如调用
get_type_hints()或运行 mypy）才解析 - 避免因类/函数定义顺序引发的导入时崩溃
- 兼容
typing.get_origin()、typing.get_args()等反射操作
get_type_hints() 是真正的性能敏感点
这个函数会实际解析字符串注解、构造类型对象、处理泛型参数——它不是零成本操作。常见踩坑场景：
立即学习“Python免费学习笔记（深入）”；
- 在热路径（如高频 API 路由、数据序列化循环）里反复调用
get_type_hints(func) - 对带复杂泛型嵌套的注解（如
dict[str, list[Union[int, str]]]）做实时解析 - 未缓存结果，每次调用都重新 parse 字符串 + 构造 AST + 绑定类型变量
实操建议：
– 首次使用后把结果存进函数的 __annotations_cache__ 属性（或用 functools.lru_cache 包裹）
– 若只用于校验，考虑改用 typing.is_typeddict() 或 isinstance(obj, typing.GenericAlias) 这类轻量判断
PEP 695 声明式泛型（class C[T]:）不增加运行时开销
这种新语法只是编译期语法糖，生成的字节码和老式 Generic[T] 完全等价。它不创建额外类属性，也不改变 __orig_bases__ 结构，更不会让实例化变慢。
但要注意：
- 如果你在泛型类内部大量使用
T做运行时类型检查（比如isinstance(x, T)），那瓶颈是isinstance本身，不是语法 -
deffoo[T](x: T) -> T:这种函数签名里的T在运行时不保留——它只参与静态分析，调用时T已擦除 - 真正有代价的是
typing.TypeVar的约束检查（如bound=SupportsFloat），因为可能触发isinstance或协议检测
真正拖慢启动/导入的其实是类型检查器配置
很多项目把 mypy 或 pyright 配成 pre-commit hook，或在 IDE 中启用实时检查——这些工具会递归扫描所有 .py 文件，解析 AST、构建符号表、推导类型流。这不是 Python 解释器干的，但用户常误以为是“Python 3.12 类型提示变慢了”。
典型症状：
-
import mymodule没变慢，但mypy mymodule.py耗时明显增加 - 升级到 3.12 后，VS Code 的 PyLance 卡顿，但
python -c "import mymodule"正常
解决方向很明确：关掉不必要的检查项，用 pyproject.toml 限制 mypy 的 follow_imports = silent，或对大型第三方依赖加 [[tool.mypy.overrides]] 跳过。
Python 3.12 的类型系统设计原则很清晰：一切可选、一切延迟、一切不侵入运行时。真正容易被忽略的，是开发者把“类型检查”和“Python 执行”混为一谈——它们发生在完全不同的时间点、不同的进程、甚至不同的机器上。
