Python中何时用类而不是函数

Python中类与函数的选择本质是权衡状态管理与行为组织的复杂度：当需要跨调用保持状态（如计数器、缓存、连接池）、封装多个强关联变量、共享上下文、支持多态扩展或处理复杂初始化（如文件打开、数据库连接）时，类能提供清晰的结构、更好的可维护性和类型安全性；而无状态、单次执行、参数完全临时的场景（如日期解析、字符串处理）则函数更简洁直接——关键不是语法形式，而是你的数据和逻辑是否已开始“互相牵扯”，选对抽象才能让代码既健壮又易懂。

状态需要跨调用保持时，用类

函数每次调用都是干净的，没有记忆；类通过实例属性能自然保存中间状态。比如实现一个计数器、缓存器、连接池管理器，或者带配置上下文的解析器——这些场景下硬用函数就得靠闭包或全局变量，反而更难维护。

常见错误现象：UnboundLocalError 或反复传一堆参数（如 config、cache、retry_count）；函数签名越来越长，调用方越来越懵。

• 状态简单且只在单次流程内流转（如数据清洗流水线中的某一步），用函数更直接
• 状态涉及多个相关变量（如 self._buffer + self._offset + self._encoding），类能天然封装它们的生命周期和约束关系
• 如果状态要被多个独立函数共享，又不想用全局变量，类是最小成本的“命名空间+状态容器”

需要多态或未来可能扩展行为时，用类

当你已经预见到不同数据源要走不同逻辑（比如 FileReader 和 APIReader 都有 read() 方法），或者现在只是读 CSV，但三个月后大概率要支持 JSON、Parquet——这时候提前用类定义接口，比后期把一堆函数塞进 if/elif 分支里干净得多。

性能影响很小：Python 的方法查找开销在绝大多数业务场景里可忽略；但可读性和后续修改成本差异巨大。

• 函数适合“做一件事，做完就结束”；类适合“代表一个东西，它能做几件事，而且这些事有关联”
• 别为了“可能扩展”过早抽象——但如果已经有两个相似逻辑（哪怕只是 copy-paste 修改了两行），就是类的信号
• isinstance(obj, Reader) 比检查 hasattr(obj, 'read') 更明确，也更容易被 IDE 和类型检查器（如 mypy）识别

构造逻辑复杂、依赖外部资源时，用类

初始化就要打开文件、连接数据库、加载模型权重、验证配置……这类操作不适合塞进函数默认参数（因为会强制执行），也不该让调用方自己拼一堆 setup 步骤。类的 __init__ 天然承担这个职责，失败就抛异常，成功才拿到可用实例。

容易踩的坑：把耗时操作（如网络请求）写在 __init__ 里却不提供延迟加载选项，导致实例化即阻塞；或者没做资源清理，忘了写 __del__ 或上下文管理协议。

• 构造失败应抛出具体异常（如 OSError、ValueError），而不是返回 None 或静默失败
• 如果资源获取昂贵或可选，考虑用 @property 或单独的 connect() 方法延迟初始化
• 用 __enter__/__exit__ 支持 with 语句，比手动 try/finally 更可靠

函数足够用，就别动类

很多工具函数（如 parse_date、slugify、deep_merge）输入确定、无状态、不依赖上下文——它们就是函数该干的事。强行套一层类，只会多出 self、__init__、实例化调用，还可能误导别人以为这东西有隐藏状态。

一个很实在的判断点：把函数所有参数列出来，再看有没有哪个参数是“反复传、几乎不变、且和其他参数强绑定”的。如果有，那可能是类的边界；如果全是临时值、每次调用都不同，函数更合适。

• 别用类模拟命名空间（如 Utils.string_utils.trim()）——模块级函数加分组注释更轻量
• 别为单个方法写类（除非它真需要状态或未来一定扩展）
• 类型提示里写 Callable[[str], int] 比写 class Counter 更直白，当函数就是函数

类不是银弹，它的价值在于组织关联状态和行为，而不是语法上的“看起来更正式”。什么时候该用，取决于你手里的数据和逻辑是否真的开始互相牵扯。

到这里，我们也就讲完了《Python中何时用类而不是函数》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！