python 3.9起可用list[str]替代list[str]，因pep 585使内置类型原生支持泛型，消除typing导入负担，提升可读性与类型检查稳定性。
直接用 list[str] 而不是 List[str] 是因为语法更直白
Python 3.9 之前，你必须从 typing 模块导入大写类型名，比如 List、Dict、Tuple，哪怕你实际操作的是小写的 list() 或 dict()。这种大小写割裂让新人困惑，也增加了维护成本——比如改一个类型注解，还得同步检查是否漏了 from typing import Set。
3.9 引入 PEP 585 后，list、dict、tuple、set、frozenset、type 这些内置类型原生支持方括号参数化。它们不再是“只是运行时类型”，而是能直接当泛型构造器用的 GenericAlias 对象。
常见错误现象：
- 在 Python 3.8 环境下写了
def f(x: list[str]) -> dict[str, int]: ...，运行时报SyntaxError: invalid syntax - 误以为
list[str]是某种“新容器类”，试图调用list[str](...)实例化，结果抛出TypeError
dict[str, int] 和 Dict[str, int] 的行为差异不只是写法问题
表面上看只是少了一行 from typing import Dict，但底层机制变了：前者是 types.GenericAlias，后者是 typing._GenericAlias（3.8 及以前）。mypy、pyright 等工具对两者的解析路径不同，尤其在嵌套泛型或与 Protocol 配合时，dict[str, int] 更稳定。
使用场景中要注意：
-
dict[str, int]在运行时可被isinstance(x, dict)正常识别；而Dict[str, int]是抽象类型，不能用于运行时检查 - 如果你用
__annotations__动态读取类型信息，3.9+ 中拿到的是dict[str, int]（即types.GenericAlias实例），其__origin__是dict，__args__是(str, int)—— 结构更干净 - 某些旧版序列化库（如
pydantic v1）不认list[str]，会报ValueError: Unknown type；升级到 pydantic v2 后才完全支持
跨版本兼容时，别硬扛，该切就切
如果你的项目要同时支持 Python 3.8 和 3.9+，不要试图写“条件导入”来混用两种写法。那会让类型检查器混乱，也会增加阅读负担。
更务实的做法是：
- 明确最低支持版本：如果是库作者，建议把
requires-python = ">=3.9"写进pyproject.toml，然后统一用小写形式 - 如果真要兼容 3.8，就老实用
typing.List等，别为了“看起来新”而引入if sys.version_info >= (3, 9): ... else: ...分支 - 注意
typing.Optional和Union不受 PEP 585 影响，它们仍需导入；但 Python 3.10+ 可用str | None替代Optional[str]，这是另一层简化
容易被忽略的一点：tuple[str, int] 不等于 tuple[str, int, ...]
很多人以为 tuple[str, int] 就是“两个元素的元组”，其实它表示**固定长度为 2 的元组**，和 typing.Tuple[str, int] 完全等价。而可变长元组得写成 tuple[str, ...]（注意三个点），这和 typing.Tuple[str, ...] 对应。
这个细节在函数返回值或数据验证场景里特别关键：
-
def get_pair() -> tuple[str, int]:表示一定返回二元组，IDE 和 mypy 会检查是否恰好两个元素 -
def get_tags() -> tuple[str, ...]:表示返回任意长度的字符串元组，包括空元组() - 写成
tuple[str, int]却返回("a", "b", "c")，mypy 会报错；但写成tuple[str, ...]就不会
别小看这点区别——它决定了类型系统能不能帮你拦住长度错配的 bug。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
