Pyright 在处理泛型联合类型（如 Callable[[T1], T2] | Callable[[T1, T1], T2]）时，对未定义 __add__ 的用户自定义类可能因参数类型推断为 Unknown 而绕过运算符检查，导致本应报错的 a + b 未触发类型错误。
pyright 在处理泛型联合类型（如 `callable[[t1], t2] | callable[[t1, t1], t2]`）时，对未定义 `__add__` 的用户自定义类可能因参数类型推断为 `unknown` 而绕过运算符检查，导致本应报错的 `a + b` 未触发类型错误。
在使用 Pyright 进行静态类型检查时，以下代码看似应全部报错，但实际行为存在差异：
from typing import Callable
class C:
pass
type F[T1, T2] = Callable[[T1], T2] | Callable[[T1, T1], T2]
# ✅ 正确报错：参数数量不匹配
b: Callable[[C], C] = lambda a, b: a + b # error: too many args
# ✅ 正确报错：C 不支持 +
a: Callable[[C, C], C] = lambda a, b: a + b # error: Operator "+" not supported
# ❌ 意外通过：无错误提示
c: F[C, C] = lambda a, b: a + b # no error —— 问题所在根本原因：Unknown 类型的隐式宽容性
Pyright 在推断匿名函数 lambda a, b: a + b 的类型时，由于未显式标注参数类型，会将 a 和 b 推断为 Unknown（而非 C）。而 Unknown 在 Pyright 中具有类似 Any 的“宽容”语义：
- Unknown + Unknown 不触发运算符检查；
- 返回值也被推断为 Unknown；
- Callable[[Unknown, Unknown], Unknown] 可被协变兼容地赋值给 Callable[[C, C], C]（因 Unknown 可接受任何类型作为输入，且 Unknown 可赋值给 C）。
这并非 Pyright 的 bug，而是其类型推断策略与 Unknown 语义共同作用的结果——它优先保障类型兼容性，而非强制严格推断。
验证与修复方法
✅ 显式标注参数类型（推荐）
强制 Pyright 使用预期类型进行检查：
c: F[C, C] = lambda a: a + a # error: too few args c: F[C, C] = lambda a, b: a + b # now errors: Operator "+" not supported for "C" and "C" # ↑ 但需显式注释：lambda a: C, b: C → C 无法直接写，改用函数定义更清晰
更可靠的方式是使用具名函数并标注：
def c_impl(a: C, b: C) -> C:
return a + b # ✅ 此处明确报错
c: F[C, C] = c_impl # ✅ 触发预期错误✅ 补充 __add__ 方法（按需）
若 C 确实应支持加法，定义协议或实现：
class C:
def __add__(self, other: "C") -> "C":
return C() # 或具体逻辑
a: Callable[[C, C], C] = lambda a, b: a + b # ✅ 通过
c: F[C, C] = lambda a, b: a + b # ✅ 通过（且类型安全）⚠️ 注意事项
- Unknown ≠ Any：Unknown 是 Pyright 内部用于“暂未推断出具体类型”的占位符，虽行为宽松，但不会污染其他上下文；
- 联合类型 | 的匹配是结构性的，只要 lambda 类型能匹配任一成员（如 Callable[[Unknown, Unknown], Unknown] 匹配 Callable[[C, C], C]），即视为合法；
- 此行为在 Pyright 1.1.360+ 版本中一致，非版本缺陷，也非 Python 类型系统限制，而是类型检查器的设计权衡。
总结
当使用泛型联合类型别名（如 F[T1, T2]）时，避免依赖隐式 lambda 参数推断。为确保类型检查的准确性，请始终：
- 对关键 lambda 显式标注参数与返回类型（可通过 typing.cast 或辅助函数）；
- 优先使用具名函数替代复杂 lambda；
- 在用户类中明确定义所需运算符方法，或使用 typing.Protocol 声明接口约束；
- 将 Unknown 视为“推断不充分”的信号，而非可忽略的中间状态。
这样既能发挥 Pyright 的强检查能力，又能规避因类型推断宽松性导致的漏报问题。
