该用类时用类，该用函数时用函数：状态需跨调用保持、多变量封装、共享状态、需多态或构造复杂时选类；无状态、单次执行、参数全临时时选函数。
状态需要跨调用保持时，用类
函数每次调用都是干净的，没有记忆；类通过实例属性能自然保存中间状态。比如实现一个计数器、缓存器、连接池管理器，或者带配置上下文的解析器——这些场景下硬用函数就得靠闭包或全局变量，反而更难维护。
常见错误现象：UnboundLocalError 或反复传一堆参数（如 config、cache、retry_count）；函数签名越来越长，调用方越来越懵。
- 状态简单且只在单次流程内流转（如数据清洗流水线中的某一步），用函数更直接
- 状态涉及多个相关变量（如
self._buffer+self._offset+self._encoding），类能天然封装它们的生命周期和约束关系 - 如果状态要被多个独立函数共享，又不想用全局变量，类是最小成本的“命名空间+状态容器”
需要多态或未来可能扩展行为时，用类
当你已经预见到不同数据源要走不同逻辑（比如 FileReader 和 APIReader 都有 read() 方法），或者现在只是读 CSV，但三个月后大概率要支持 JSON、Parquet——这时候提前用类定义接口，比后期把一堆函数塞进 if/elif 分支里干净得多。
性能影响很小：Python 的方法查找开销在绝大多数业务场景里可忽略；但可读性和后续修改成本差异巨大。
立即学习“Python免费学习笔记（深入）”；
Python v2.4版chm格式的中文手册，内容丰富全面，不但是一本手册，你完全可以把她作为一本Python的入门教程，教你如何使用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更直白，当函数就是函数
类不是银弹，它的价值在于组织关联状态和行为，而不是语法上的“看起来更正式”。什么时候该用，取决于你手里的数据和逻辑是否真的开始互相牵扯。
