为什么很多资深开发者对 Python 心存芥蒂？

Python 在脚本自动化、数据分析、原型验证等场景中有着无可争议的地位。但一个有趣的现象是：不少从其他语言转过来的资深工程师，在接手过一两个中大型 Python 项目之后，会对它产生明显的抵触情绪。这种抵触并非出于语言偏见，而是被现实工程问题反复摩擦之后形成的理性判断。

本文不讨论“Python 好不好”，而是聚焦一个更有价值的问题：在哪些工程条件下，Python 会从高效工具演变为维护负担？以及团队应当如何规避这些陷阱。

一、从一次典型的“遗留项目考古”说起

一个常见的场景是这样的：某团队接手了一份 Python 代码库，原作者已经离职，项目没有文档，没有类型标注。想要理解任意一个函数的调用关系，只能依靠全局文本搜索加上经验推断。

更具体的困难在于：

• 单个文件动辄数百行，函数参数全部使用 **kwargs；
• 数据结构一律用 dict 传递，没有明确的结构定义；
• 返回值是什么、是否可能为 None，全靠阅读实现细节判断；
• 模块之间的依赖关系没有显式声明，只能通过搜索字符串来重建。

在这种代码里，即便是“这个变量到底传了什么进去”这样基础的问题，也需要花费大量时间去追踪。至于可空性、参数约束、副作用边界这些稍高层次的问题，更是无从谈起。

于是出现了一个并不罕见的结论：照着原代码重写几个模块，反而比复用原有代码更省时间。 这并非说明重写总是正确的，而是说明当代码的可理解性跌到某个阈值以下时，阅读成本会超过重建成本。

这背后真正的问题，不是“Python 项目容易写乱”，而是Python 允许你在没有约束的情况下快速交付，而工程规模的膨胀会成倍放大这种自由的代价。

二、痛点拆解：动态类型带来的连锁反应

1. 类型信息的缺失让工具链失效

静态类型语言中，编译器本身就是第一道防线：参数类型不匹配、返回值未处理、属性不存在等问题会在构建阶段暴露。而在缺少类型标注的 Python 代码中，这些问题全部推迟到运行时，甚至推迟到线上。

由此产生的连锁反应包括：

• IDE 无法提供可靠补全：没有类型信息，智能提示只能靠猜，重构工具也难以安全地重命名或提取方法。
• 静态检查形同虚设：类型检查工具在缺乏标注时几乎无法发挥作用，能发现的只是一些明显的未定义变量。
• 测试成为唯一的验证手段：当类型系统缺位时，团队只能依靠覆盖率来获得信心，而测试本身的维护成本又会随代码规模上升。
• 文档与代码容易脱节：本应由类型承载的契约信息，被写在注释或口头约定中，一旦代码变更就可能失真。

2. 数据结构退化为“万能字典”

用 dict 承载一切数据是另一个高频问题。字典的问题不在于不能表达结构，而在于它不强制任何结构：

# 调用方无法知道这个函数需要哪些 key
def process_order(order):
    return order["items"], order["user"]["id"]
# 而使用显式结构时，契约是自描述的
from dataclasses import dataclass
@dataclass
class Order:
    items: list
    user_id: str
def process_order(order: Order) -> tuple:
    return order.items, order.user_id

字典的键名没有拼写检查，没有自动补全，没有默认值约束，重命名键名时也无法被工具安全追踪。数据在多个模块间流转时，结构会逐渐漂移，最终形成“只有原作者知道”的隐性知识。

3. 参数爆炸与 **kwargs 的滥用

**kwargs 在某些场景下确实提供了灵活性，比如装饰器、通用包装层。但当它被用作常规函数的参数传递方式时，问题就出现了：

• 函数签名不再表达意图，调用者必须阅读实现才能知道支持哪些参数；
• 参数校验被推迟到函数内部，错误信息往往模糊；
• 重构时无法定位所有调用点，因为参数名可能由调用方拼接而来。

这本质上是用运行时的灵活性换取了编译期的可验证性，在长期维护的项目中通常是亏本交易。

三、为什么这些问题在 Python 中更突出

其他语言也有动态类型分支，也有大型遗留项目，但 Python 的几个特性放大了上述问题：

第一，语法简洁带来的低门槛。 一个没有工程经验的开发者可以在很短时间内写出“能跑”的代码，而“能跑”和“可维护”之间的距离，往往要到项目进入维护期才暴露。

第二，缩进即语法。 这在强调结构清晰的同时，也让大段逻辑难以通过简单的格式化工具进行分层重构，深层嵌套的可读性下降更快。

第三，多重编程范式并存。 面向对象、函数式、过程式可以混写，缺少统一的工程约定时，不同模块的风格差异会显著增加理解成本。

第四，解释执行与全局状态。 模块级变量、导入副作用等问题在大型项目中难以静态分析，容易出现隐蔽的初始化顺序依赖。

第五，性能敏感场景需要下沉。 当项目遇到性能瓶颈时，常见做法是将热点逻辑用其他语言实现并封装调用。这本身是合理方案，但同时也意味着项目会变成多语言混合体，构建、调试、部署的复杂度都会上升——这并非 Python 独有的问题，但在以 Python 为主的项目中尤为常见。

四、工程化视角下的应对策略

问题清晰之后，解决方案也就有了方向。以下是经过实践检验的几条原则。

原则一：把类型标注当作契约，而不是可选项

对新项目，从第一行代码开始就写类型标注；对遗留项目，可以在修改某个模块时顺手补全该模块的标注。工具层面的投入会很快收回成本：

• 类型检查工具可以在提交前拦截大量低级错误；
• IDE 补全和跳转能力大幅提升；
• 类型定义本身成为最不易过时的文档。

from typing import Optional
def find_user(user_id: str) -> Optional[User]:
    ...

这一行签名传达的信息，比一段注释更可靠。

原则二：用显式结构替代裸字典

对于跨模块传递的数据，优先使用数据类、命名元组或具名结构。它们的收益是复合的：可读性、可补全、可校验、可演进。

原则三：控制函数签名的表达力

慎用 **kwargs 作为常规参数入口。如果参数确实很多，考虑引入配置对象，而不是让调用方猜测参数名。

原则四：建立模块边界与依赖规则

大型 Python 项目常见的问题是模块间随意互相导入。可以通过分层约定和依赖检查工具，让架构约束变成可自动验证的规则，而不是口头共识。

原则五：把文档和注释留给“为什么”，而不是“是什么”

类型和结构负责表达“是什么”，注释负责解释“为什么这样设计”。职责分清之后，文档的过时速度会明显下降。

五、结语

对 Python 的抵触，本质上不是对语言的抵触，而是对缺乏工程约束的快速开发模式的抵触。Python 给了开发者很大的自由，而自由在小型脚本中是效率，在大型系统中则可能变成债务。

成熟的团队不会因为语言本身做取舍，而是会根据项目规模、生命周期、性能要求来选择合适的工具，并为之配套相应的工程规范。类型标注、显式结构、清晰的模块边界，这些手段在其他语言中可能是默认存在的，在 Python 中则需要团队主动建立。建立得越早，后面接手代码的人就越少经历那种“靠全局搜索加猜测”的困境。

这或许才是那个现象背后真正值得讨论的问题：不是为什么有人不喜欢 Python，而是为什么有些 Python 项目让人不得不靠辞职来逃离。答案是可以通过工程实践改变的。