class Container[T]: 更直接，因为解释器在语法层面就识别T为类型形参，无需导入TypeVar和继承Generic[T]；T作用域限于类内，多参数写作Map[K, V]，泛型别名必须用type Stack[T] = list[T]，运行时无强制，仅服务静态检查。
class Container[T]: 为什么比 class Container(Generic[T]): 更直接
因为解释器在语法层面就识别出 T 是类型形参，不用绕一圈先导入 TypeVar、再声明变量、再让类继承 Generic[T]。整个泛型契约从“运行时协议”变成了“语法结构”，IDE 和类型检查器能更早、更稳地绑定类型。
常见错误现象：NameError: name 'T' is not defined 多半是旧写法残留——比如漏了 from typing import Generic, TypeVar，或忘了 T = TypeVar('T') 这一行。
-
class Stack[T]:中的T作用域严格限定在该类定义块内，类外不能引用，避免命名污染 - 多个参数直接写成
class Map[K, V]:，顺序和语义由你定义，不强制K必须是键、V必须是值，但建议保持惯例 - 不支持省略方括号：
class Stack:就是普通类；class Stack[T]:才是泛型类——这是语法硬性要求，不是风格选择
type Stack[T] = list[T] 为什么不能写成 Stack[T] = list[T]
因为没加 type 关键字，Python 解释器会把它当普通赋值语句处理，T 在右侧出现前未声明，直接报 NameError；即使侥幸运行成功（比如提前定义了 T），mypy 也不会识别为泛型别名，无法做类型推导。
使用场景：定义协议返回类型、工厂函数签名、中间类型封装——这些地方需要类型检查器理解“这是一个可参数化的类型”，而不是一个固定类型的别名。
立即学习“Python免费学习笔记（深入）”；
- ✅ 正确：
type Stack[T] = list[T]——T自动绑定，Stack[int]被识别为list[int] - ❌ 错误：
Stack[T] = list[T]——NameError - ❌ 半正确：
Stack = list[T]—— 运行时不报错，但类型检查器忽略泛型语义
泛型函数 def first[T](items: list[T]) -> T: 的参数绑定逻辑
函数体内的 T 不是全局变量，也不是模块级 TypeVar 实例，而是函数签名中声明的类型形参，只在该函数作用域内有效。调用时类型检查器根据实参自动推断 T，比如 first([1, 2, 3]) 推出 T 是 int。
容易踩的坑：在函数外部写 def f(x: T) -> T: 会直接失败——T 在这里根本没定义，不是配置问题，是语法设计如此。
- 不需要
from typing import TypeVar，也不用引号包裹T - 不支持默认值：
def process[T](data: T | None = None) -> T:合法，但= None是运行时值，不影响T的类型约束 - 多个形参如
def merge[K, V1, V2, R](...)，每个都独立作用域，互不干扰
泛型类实例化时类型参数是否必须显式写出
不必。Python 3.12 允许省略类型参数，靠实参类型自动推断，比如 box = Box("hello")，mypy 会推断为 Box[str]；但显式标注 box: Box[int] = Box(42) 更利于意图表达和跨文件类型传播。
性能 / 兼容性影响：泛型纯属静态检查范畴，运行时不做强制，构造 Box[str](42) 不会崩溃，但 mypy 会报 Argument 1 to "Box" has incompatible type "int"; expected "str"。
- 类方法中对
T的引用（如def get(self) -> T:）自动绑定到实例化时确定的类型 - 嵌套泛型如
type Pair[K, V] = tuple[K, V]，比老写法class Pair(Generic[K, V]):更轻量，也更容易组合 - 最容易被忽略的是作用域边界——
T只活在它被声明的那个class或def里，跨作用域复用会直接失败
