Python 何时不该写类型提示？

类型提示非必需，仅在多人协作、长期维护、需明确接口契约时最有价值；快速原型、临时脚本、高度动态代码、无类型检查流程、性能敏感热路径等场景下可省略。

类型提示不是必须的，尤其在某些场景下加了反而降低可读性或增加维护成本。关键看是否真正带来收益。

快速原型或临时脚本

写一个一次性爬虫、数据清洗小工具，或 jupyter 里探索数据时，加类型提示往往拖慢节奏，且后续大概率不会复用或长期维护。python 的动态特性此时是优势，不是缺陷。

• 函数参数简单（比如只有 str 或 int），行为一目了然
• 没有外部调用方，不涉及接口契约
• 运行完就丢，不进版本库或 CI 流程

高度动态的代码模式

当你依赖 getattr、__getattr__、exec、eval，或大量使用 Any / union / TypedDict 嵌套到难以维护的程度时，类型提示可能变成“自欺欺人”。

• 类型信息在运行时才确定，静态检查器无法真正验证
• 硬写类型可能掩盖设计问题（比如该重构为配置驱动，而非靠字符串分发）
• Any 泛滥说明类型系统已失效，不如先简化逻辑

团队未统一采用类型检查工具

如果项目没配 mypy/pyright，也没跑类型检查 CI，类型提示就只是注释——既不校验，也不强制，还可能过期失真。这时它反而制造假安全感。

立即学习“Python免费学习笔记（深入）”；

• 函数签名改了但类型没更新，提示变误导
• 新人误以为“有类型=安全”，忽略实际测试和边界处理
• 文档字符串更轻量、更易同步，对内部脚本常更合适

性能敏感的热路径（极少数情况）

类型提示本身不运行，但若配合 typing.get_type_hints() 或运行时反射（如某些 ORM、序列化库），可能引入不可忽视的开销。高频调用的底层函数要谨慎。

• 不是指写 def f(x: int) -> str: 有性能问题，而是反射读取类型的过程
• 可通过 if TYPE_CHECKING: 延迟导入复杂类型，避免运行时加载
• 优先测真实瓶颈，别为“可能的开销”提前牺牲可读性

类型提示是工具，不是教条。它最有价值的地方，是多人协作、长期演进、需要明确接口契约的模块。随手写的三行函数，不加也没关系。