闭包在轻量状态封装中性能优于小型类，因其避免实例对象开销、直接访问cell变量且共享code对象；但多字段、多方法或需类型检查时，类更合适。
闭包在多数简单状态封装场景下，内存开销和调用开销确实低于等效的小型类。这不是绝对优势，而是由 Python 对函数对象和实例对象的底层实现差异决定的。
闭包不创建实例对象，避免了 __dict__ 和属性查找开销
小型类（比如只带一个 count 属性和一个 increment 方法）每次调用 Counter() 都会生成新实例，该实例默认携带一个 __dict__ 字典用于存储属性。即使你用 __slots__ 优化，仍需分配实例对象头、维护引用计数、走完整的属性访问路径（__getattribute__ → 描述符 → 实际值）。
而闭包返回的是函数对象，其捕获的自由变量（如 count）直接存于函数的 __closure__ 元组中，访问时走的是极快的 C 层级 cell 访问路径，没有字典哈希、无描述符解析、无实例属性查找。
- 闭包读写
count：直接解引用func.__closure__[0].cell_contents - 类实例读写
self.count：触发PyObject_GetAttr，查__dict__或__slots__，再取值
闭包共享代码对象，类实例各自持有方法绑定
同一个闭包工厂（如 counter()）产生的所有闭包函数，共用同一份字节码和常量表；它们只是不同的函数对象，指向相同的 code 对象。
立即学习“Python免费学习笔记（深入）”；
而类的每个实例方法调用（如 c1.increment()）都会动态生成一个绑定方法（bound method）对象——它包装了实例和函数，每次调用都涉及一次方法绑定开销（虽然有缓存，但首次仍需构造）。
- 闭包调用：
func()直接进入函数体 - 类方法调用：
c1.increment()先查c1.__dict__或类的__dict__，找到函数，再绑定，再调用
容易踩的坑：闭包不是万能加速器
闭包的性能优势集中在「轻量状态 + 单一行为」场景。一旦你需要多个字段、多种方法、类型检查或继承，闭包反而会迅速变重：
- 多个自由变量 →
__closure__变长，cell 访问链变长 - 模拟多个方法 → 得靠
if/elif分支或返回元组，丧失语义清晰性 - 无法被
isinstance判断，调试时type(func)永远是<class 'function'>，丢失领域语义 - 闭包无法被
dataclass或NamedTuple替代，缺乏结构化约束
真正影响选择的，往往不是微秒级的执行差异，而是你是否需要把「状态 + 行为」显式建模为一个可识别、可扩展、可序列化的实体——这时候类就不再是“更慢”，而是“更合适”。
