• 2026 年 Python 类型调查共收到 1,794 份回答。
  • 类型提示的使用情况在三年间变化不大，但检查器的选择发生了显著变化。
  • 在报告了所用检查器的受访者中，一半选择了不止一个；缺少库的类型信息是最常见的困难。

我们连续第三年询问 Python 开发者如何使用 Python 类型，以及他们的使用体验：包括用于描述和检查 Python 代码中类型的语言特性、规范和工具。我们开展这项调查，是为了了解哪些方面运作良好，以及库维护者、工具开发者、文档作者和标准贡献者接下来应该解决哪些问题。

大多数受访者都是经验丰富的 Python 开发者：76.4% 使用 Python 已至少五年。最明显的变化是检查器选择的转变，而缺少库的类型信息仍然是最常见的困难。

2026 年 Python 类型调查的主要发现

今年的调查结果显示了几个反复出现的改进机会：

更全面、更准确的类型信息将有助于数据科学软件包的用户：动态框架带来了另一种挑战，因为当前的类型系统无法表达某些运行时行为。可能的方向包括新的类型特性，以及为各个库和框架量身定制的检查器支持。

工具开发者可以重点改进编辑器反馈，以及只需少量配置即可完成的首次检查：错误信息可以链接到简短的说明和示例。类型文档可以假定读者已有 Python 经验。使用多个检查器的项目，也会受益于对检查器之间有意保留的差异所作的清晰说明。

改进 Callable 语法仍是标准制定工作中一个务实的方向，尤其是当改进能够让常见的类型任务保持简单时。

AI 的使用仍是一个未决问题：有关 AI 的调查结果留下了一个问题，即 AI 工具与类型检查器之间的哪些交互能帮助开发者。进一步的实证研究可以为未来的设计提供参考。

AI 工具如今会编写类型并处理检查器错误

选择“让 AI 生成的代码更加准确可靠”的受访者比例，从 2025 年的 18.5% 上升到 2026 年的 38.4%。在 1,517 名受访者中，42.5% 让 AI 工具编写类型提示，32.6% 则编写类型来改进 AI 生成的代码。受访者还使用 AI 修复或解释类型错误。在列出的四项与类型相关的 AI 工具使用活动中，61.0% 的受访者表示至少使用过其中一项。

一些受访者表示，他们的 AI 编程工具会运行检查器，然后修复错误。在回答了如何运行检查器的 1,517 名开发者中，24.4% 表示 AI 编程工具会调用他们的检查器。在这 370 名受访者中，61.6% 也使用 AI 修复检查器报出的错误。其余受访者中的这一比例为 19.3%。

一些受访者提到，AI 生成的类型过于宽泛，以及智能体会屏蔽检查器错误：

“我会修复 AI 编写的类型提示，因为 AI 经常偷懒，所有东西都用 object。”

“偷懒的编程智能体到处滥加 #type: ignore 注释。”

当被问及类型对改进 AI 辅助编程有多大帮助时，1,551 名受访者中有 29.8% 选择了“我不确定”。AI 辅助编程的不确定比例接近运行时保障的四倍；后者在六项收益中排名第二，不确定比例为 7.7%。我们仍需要实证证据，来了解哪些交互真正有帮助。

Pyrefly 团队已经在研究 AI 编程工具和类型检查器如何协同工作。在 2026 年 Python 类型峰会上，该团队发表了 智能体工作流中的类型检查。

库的类型信息缺失最为普遍；偶尔使用的开发者苦于复杂性

第三方库缺少类型信息是最主要的困难，在 1,486 名受访者中有 65.1% 选择了这一项。另有 44.6% 表示，类型系统无法描述他们的代码所做的一切。

即使库提供了专用的类型存根，开发者的体验仍可能不佳。在 156 名自行填写回答的受访者中，22 人提到了动态结构、装饰器、元编程或框架行为。十人提到了数组、数据框或科学计算中的类型标注，至少八人提到类型注解不准确、不完整或过于宽泛。受访者反复提到了 Django、SQLAlchemy、Pydantic、NumPy、pandas 和 Polars。

“Django 用了太多黑魔法，类型检查器居然还能工作，简直是个奇迹。”——调查受访者

库维护者需要能够准确描述框架和数据科学库行为的类型注解。Pyrefly 团队一直在与 Quansight 合作改进第三方库的类型支持，其中包括向 pandas-stubs 和 NumPy 作出贡献。

使用频率影响了哪些问题更为突出。在很少或有时使用类型提示的开发者中，41.6% 认为类型系统过于复杂或冗长。在经常或总是使用类型提示的开发者中，这一比例为 14.5%。库的类型信息缺失影响了低频使用组中的 36.2% 和高频使用组中的 70.0%。

“我使用简单易懂的部分，避开难以理解的部分。”——调查受访者

类型使用经验的年限则呈现出不同的规律。拥有零到两年类型使用经验的受访者中，18.2% 报告了复杂性问题；拥有三到六年经验的受访者中，这一比例为 16.0%；拥有七年及以上经验的受访者中，这一比例为 21.0%。类型新手往往也是经常使用类型的用户和经验丰富的 Python 开发者：在 396 名拥有零到两年类型使用经验的受访者中，306 人（77.3%）经常或总是使用类型提示，345 人（87.1%）使用 Python 已至少三年。

面向类型新手的开发者指南应假定他们已有 Python 经验，并展示如何为现有代码仓库添加类型。偶尔使用的开发者需要只需少量配置即可获得有用的首次检查结果，以及易于理解的错误信息。在改进类型系统时，我们应力求支持更多模式，同时不增加常见任务的难度。

改进 Callable 语法是一个务实的切入点。它是最常被选为缺失功能的选项，在回答该问题的 1,486 名受访者中有 45.7% 选择了它。报告了复杂性问题的受访者与其余受访者选择这一项的比例相近。

较新的检查器迅速普及

在三次调查中，经常使用类型提示的比例始终在 85.5% 到 88.0% 之间：2024 年为 88.0%，2025 年为 85.9%，2026 年为 85.5%。每年回答调查的群体不同，但总体比例保持稳定。

检查器的选择则远没有这么稳定。2024 年 Python 类型调查询问 Python 类型系统缺少什么功能时，有一条回答如今看来像是对今年调查结果中所记录变化的预告：

“更快的 Mypy。它速度不够快，导致生态系统分裂，而且其他类型检查器不支持 Mypy 插件，整体行为也不一样。”——调查受访者

到 2026 年，开发者已经有多个较新的开源检查器可供选择。速度或性能是选择检查器的首要原因，比例为 56.5%。以两年相同的检查器名单计算，2026 年有 49.9% 的受访者选择了两个或更多，比 2025 年的 46.0% 有所上升。

开发者在工作流程中混用检查器

在选择 Mypy 的 700 名受访者中，297 人也选择了它的编辑器插件。另有 314 人选择了其他具名检查器的集成，但没有选择 Mypy 插件。

大多数选择 Pyrefly 的受访者还选择了另一个检查器：264 人中有 220 人，占 83.3%。在自由填写的回答中，开发者说明了他们的团队为何将工作分配给不同的检查器：

“因为团队成员使用不同的 IDE，我们在开发时使用多个类型检查器，但依靠 Mypy 做代码检查（本地和 CI）。”——调查受访者

“在本地，我们主要使用 Pyright，因为在我们尝试过的选项中，只有它能完全理解我们代码库里所有比较冷门的类型标注模式。在 CI/CD 中，我们会运行一次 Pyrefly，然后只对 Pyrefly 检查失败的文件运行 Pyright，以提高检查性能。”——调查受访者

在回答了困难相关问题的 1,486 名开发者中，33.3% 报告了检查器之间存在不一致。在选择了多个静态检查器并回答了困难相关问题的 738 名受访者中，315 人（42.7%）报告了检查器之间存在不一致。

类型相关求助逐渐离开 Stack Overflow，IDE 支持仍然至关重要

可读性或文档是使用类型提示最常被选择的原因，在 1,571 名受访者中有 93.6% 选择了这一项。编辑器支持的排名也很高：在 1,494 名给出数字评分的受访者中，84.8% 选择了 4 或 5。在 103 名自行填写原因的开发者中，约有 39% 提到了补全、导航、悬停信息或编辑器错误信息。

“极大地改善了 IDE 的工具提示和自动补全。”——调查受访者

编辑器中的实时反馈已广泛普及：在 1,517 名受访者中，82.9% 的人会在编辑器中运行类型检查器。VS Code 是受访者选择最多的编辑器或 IDE，占比为 59.3%。

开发者寻求帮助的渠道也发生了变化。从 2024 年到 2026 年，Stack Overflow 的使用率从 46.4% 降至 22.9%，而大语言模型（LLM）聊天工具的使用率从 26.0% 升至 41.7%。Python 类型标注文档的使用率从 56.2% 升至 65.9%。特定检查器的文档使用率在 2025 年短暂下跌后，从 52.2% 升至 60.5%。通用 Python 文档的使用率从 66.7% 降至 62.2%。

随着开发者从 Stack Overflow 转向类型标注和特定检查器的文档，这些资料的质量也变得更加重要。错误消息应链接到简短、相关的解释和示例。指向文档的链接也能为 LLM 聊天工具提供更好的信息。

调查结果和原始数据

从 Python Typing Survey 2026 下载完整结果和数据。

致谢

本次调查于 2026 年 8 月 5 日至 9 月 2 日进行。调查得到了 Meta 的 Pyrefly 团队、JetBrains 的 PyCharm 团队、Microsoft 的 Python 团队、Astral/OpenAI 的 ty 团队以及 discuss.python.org 社区贡献者的支持。我们通过 Reddit、X、Mastodon、新闻简报、Python 类型标注论坛、LinkedIn、Bluesky、Discord、Slack，以及类型检查器项目的网站和社交媒体账号分享了调查。我们对引文的拼写、语法和标点进行了轻微编辑。感谢所有参与调查、分享调查、审阅数据或为 Python 类型标注社区作出贡献的人。

文章 Python Typing Survey 2026：AI 工具与不断变化的检查器格局 最初发表于 Engineering at Meta。