mypy通过静态类型推导确定变量类型：从函数签名、赋值语句和类型注解构建约束图；未注解处遇None/dict()/list()等退化为Any，reveal_type可调试推导结果。
myPy 怎么知道某个变量是 str 而不是 int
它不运行代码，也不靠运行时 introspection，而是做静态类型推导：从函数签名、赋值语句、类型注解出发，逐行构建类型约束图。比如 def greet(name: str) -> str: 这一行就锁死了参数和返回值的类型边界。
实操建议：
- 类型注解越早写越稳——函数参数、返回值、模块级常量优先加注解，避免推导链断裂
- 没注解的地方，mypy 会尝试“类型推导”，但一旦遇到
None、dict()、list()这类无参数构造，就退化为Any，后续检查基本失效 -
reveal_type(x)是调试利器：在代码里插入这句，mypy 会直接报出它当前推导出的类型，比猜强得多
为什么加了 -> None 还报错说 “Missing return statement”
这是 mypy 把 -> None 当作严格契约：你承诺这个函数绝不返回任何值（即隐式返回 None 也算违规）。而 python 解释器允许函数末尾无 return，自动补 return None —— mypy 不认这个默认行为。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 函数有分支，某些路径没写
return，即使逻辑上不会走到那里，mypy 也会报Missing return statement - 用了
if cond: return但没配else，mypy 认为“可能掉出函数末尾”，触发警告
解决方法：
- 明确补全所有控制流出口，哪怕只是加个
return None - 如果真想表达“此处绝不应到达”，用
raise AssertionError()或assert False，mypy 识别这些为“不可达路径” - 极少数情况可加
# type: ignore，但别养成习惯——它绕过的是整个检查逻辑，不是类型问题本身
union[str, int] 和 Optional[str] 在 mypy 里真的一样吗
语法等价，但语义和检查行为有差异：Optional[T] 是 Union[T, None] 的简写，mypy 内部确实等价处理；但人读代码时，Optional 暗示“这个值可能缺失”，而裸 Union 更强调“多态取值”。更重要的是——它们影响类型窄化（narrowing）的效果。
使用场景与坑点：
- 用
isinstance(x, str)判断后，Union[str, int]可被窄化为str；但对Optional[str]，只判断x is not None才能窄化，isinstance(x, str)不够（因为None不是str的实例，但 mypy 不因此排除None分支） - 函数参数声明为
Optional[str]，传入None合法；但若声明为Union[str, int]，传None就直接报错 - 配置项或 API 返回值中，显式用
Optional更利于协作理解，也方便 ide 做更好的提示
mypy 检查慢 / 内存高，是不是该关掉某些检查
慢通常不是因为检查项太多，而是因为跨文件依赖没切好，或者类型信息太“松”。比如一个模块 import 了整个 django，又没配 follow_imports = silent，mypy 就得递归解析所有第三方代码。
性能关键点：
- 在
mypy.ini里设follow_imports = silent（默认是normal），让 mypy 对未安装 stub 的第三方包跳过深入检查 - 避免在类型注解里写太复杂的嵌套，比如
Dict[str, List[Union[Callable[[int], str], None]]]—— mypy 推导成本指数级上升 - 用
reveal_locals()查看局部变量推导结果，如果发现某处推成了Any，往往意味着上游漏注解，导致后续整条链都失去约束，检查既慢又不准
类型检查不是越细越好，而是越“稳”越好：稳定指类型边界清晰、推导可预测、不频繁退化为 Any。很多性能问题，根子在类型定义的随意性上，不在 mypy 本身。