前几天一个朋友让我帮他看一个Python项目的打包问题一个看起来不算复杂的爬虫工具用PyInstaller打成exe之后居然有130多MB而且启动还慢。我打开代码一看发现他的主类里挂满了动态属性——有requests.Session、有上一次抓取到的完整HTML、有排列组合的临时DataFrame、还有一堆调试日志。这些对象在程序运行的时候确实有用但生命周期和主进程一样长。我把几个临时属性用delattr删掉之后内存直接降了一个量级再配合序列化瘦身最后打包出来的体积也肉眼可见地缩水了。这让我对delattr这个平时存在感极低的内置函数刮目相看。本文就来聊聊Python对象瘦身这件事delattr怎么用、为什么能提升代码可扩展性和打包效率、具体怎么落地到内存控制、序列化、打包和插件设计几个场景中。适合用Python写脚本、写库、跑爬虫、做数据处理还有琢磨怎么把程序打包分发的朋友们。1. delattr等于del obj.attr先拆开对象的内存结构1.1 一个Python对象的属性到底存在哪在Python里大多数实例对象的属性并不是“硬编码在类结构里”的而是存在一个叫__dict__的字典中。每次执行obj.attr value本质上就是往obj.__dict__里塞了一个键值对。你可以把对象当成一个衣柜属性名是标签属性值是挂在衣柜里的衣服__dict__就是贴在衣柜外面的衣物清单。class Downloader: pass d Downloader() d.url https://example.com print(d.__dict__) # {url: https://example.com} delattr(d, url) print(d.__dict__) # {}delattr(obj, attr)做的事情很简单从obj.__dict__中移除对应的键。如果这个属性恰好是一个数据描述符delattr还会调用描述符的__delete__逻辑。对于绝大多数你手动挂上去的普通属性来说它就是一行dict.pop。1.2 delattr和del obj.attr到底有什么区别很多人会问既然delattr(obj, attr)等价于del obj.attr为什么还要多记一个函数名区别其实只有一点delattr允许你用字符串变量来指定属性名。names [tmp_response, tmp_html, debug_trace] for name in names: if name in d.__dict__: delattr(d, name)这段逻辑如果用del关键字写就需要写三行重复代码或者用eval这种危险操作。而delattr天然适合批量清理、框架代码、装饰器、代码生成器这些场景。只要属性名是程序运行时动态拼出来的delattr就是比del更安全、更可控的选择。1.3 有哪些属性delattr删不掉delattr只会删除对象实例自身的属性不会删除类属性。举个例子class Demo: amount 10 d Demo() d.amount 5 delattr(d, amount) print(d.amount) # 10这里删除的是d实例字典里的amount删除之后访问d.amount又会回到类属性Demo.amount 10。如果你没有在实例上显式赋值直接delattr(d, amount)那么Python会因为实例字典里没有这个键而抛出AttributeError。这条规则的实操意义很大delattr清理的是实例对类属性的“遮蔽”。如果你觉得对象属性太多第一反应应该是去看看__dict__里到底有什么而不是凭类定义猜测。2. 对象越来越“胖”的三个典型现场2.1 动态注入属性写起来爽忘起来也爽Python的动态特性让“往对象上挂新属性”变得特别方便很多人在写业务代码时喜欢把中间的每一个结果都挂到self上class Crawler: def run(self): self.raw_html requests.get(self.url).text self.parsed_html parse_html(self.raw_html) self.items extract_items(self.parsed_html) self.result_df build_dataframe(self.items)写的时候确实很顺手后续方法想用哪个就用哪个。可问题是这些属性在对象销毁之前会一直存在。如果Crawler对象本身是常驻内存的单例或者被框架缓存了那么这些临时数据就会变成“永久数据”。一次两次无所谓跑上几百个URL之后对象的__dict__里会攒下大量历史残留内存占用自然飙升。2.2 缓存属性和临时状态用完之后仍然霸占位置另一种常见情况是缓存属性。为了性能确实可以把某个计算结果缓存到对象属性上class Analyzer: def get_heavy_data(self): if not hasattr(self, _heavy_data): self._heavy_data load_million_rows_from_db() return self._heavy_data这种写法本身没错错的是没有给缓存设置失效机制。如果_heavy_data只需要在某个时间段内有效之后就用不到了那它就成了纯粹的负担。更隐蔽的是临时调试属性比如self._last_error、self._debug_stack、self._log_handlers。这些属性在调试阶段很有用但到了性能测试或打包发布阶段仍然留在代码里就会被序列化、被打包、被多进程pickle传来传去造成各种莫名其妙的问题。2.3 三方框架注入的属性看不见的膨胀源还有一类属性膨胀不是你自己写的而是框架或第三方库注入的。比如某些Web框架的请求对象会动态往self上塞用户信息、session、缓存、连接池某些ORM模型会缓存查询结果、原始SQL、关系对象。你不一定每时每刻都用到它们但它们确实存在于对象的__dict__中。想搞清楚一个对象到底有多“胖”最简单的办法是直接看vars(obj)def inspect_attrs(obj, limit20): attrs vars(obj) print(f对象属性总数: {len(attrs)}) for i, (k, v) in enumerate(attrs.items()): if i limit: break print(f{k}: {type(v).__name__} - {v!r:.50})跑一下这个函数你往往会发现真正业务必需的属性只占一小半剩下的大多是临时状态、缓存、调试日志、历史数据。这时候delattr就该登场了。3. 动手瘦身从临时属性到序列化体积的完整链路3.1 给类定义一个cleanup协议最直接的做法是给类加一个cleanup()方法用delattr批量删除已知的临时属性class Crawler: def __init__(self): self.session create_session() self.raw_html None self.parsed None self.stats {} def cleanup(self): for name in [raw_html, parsed, stats]: if hasattr(self, name): delattr(self, name)这里为什么要用hasattr判断因为如果属性在之前的异常流程中已经被删过直接delattr会抛AttributeError。hasattr可以帮忙忽略掉已经不存在的情况。但是hasattr也有自己的坑如果类里定义了__getattr__和propertyhasattr会触发这些逻辑有可能产生意想不到的副作用。更精准的写法是直接判断__dict__def safe_delattr(obj, name): if name in vars(obj): delattr(obj, name)vars(obj)返回的就是实例__dict__这个判断只会看实例自身有没有属性不会触发__getattr__也不会被类属性干扰清理起来更干净。3.2 序列化之前先瘦身pickle体积下降是立竿见影的很多Python程序都需要用pickle做对象序列化比如multiprocessing传参、缓存到Redis、保存中间结果。pickle默认会把对象的__dict__整个打包所以对象里挂着多少属性序列化出来的字节数就有多大。import pickle class Report: def __init__(self): self.data list(range(100000)) self.tmp_cache {i: str(i) for i in range(100000)} r Report() print(len(pickle.dumps(r))) # 大概 1068581 字节 delattr(r, tmp_cache) print(len(pickle.dumps(r))) # 大概 467590 字节删除一个临时缓存属性pickle体积直接少了一半。如果对象里挂的是DataFrame、图片列表、模型权重这类大家伙效果会更夸张。还有一种情况是对象根本没法pickle比如里面有线程锁、文件句柄、logging handler。这时delattr甚至可以救命import threading class Worker: def __init__(self): self.data [1, 2, 3] self.lock threading.Lock() w Worker() # pickle.dumps(w) # 会报错Lock不能被pickle delattr(w, lock) data pickle.dumps(w)在实际的多进程任务里给所有需要跨进程传递的对象定义一个cleanup方法在提交前删掉不可pickle的锁、连接、句柄和临时缓存既能避免报错又能减少序列化耗时。3.3 打包效率到底怎么提升把对象属性当成“资源包”来管这里要澄清一个容易被误解的点delattr不会直接减小你的.py文件体积也不会让PyInstaller少打包几个标准库模块。PyInstaller分析的是源码里的import语句不会因为对象少了一个属性就少收集一个模块。但对象属性会通过另外两条路径影响打包产物第一条路径是数据资源。如果你的程序里有预生成的pickle数据文件、模型权重、词表、缓存结果这些文件是要作为数据文件一起打包的。对象属性中如果缓存了大量临时数据你在生成这些数据文件时就会把它们一起写进去文件自然膨胀。先delattr再保存数据文件会小很多打包体积也随之下降。第二条路径是运行时内存和启动速度。PyInstaller打包出来的程序启动时要重新初始化整个运行时环境。如果对象一启动就带着大量历史残留属性内存占用高、初始化慢、运行卡顿。把这些无用属性删掉后程序启动更快整体资源占用更低用户体验完全不一样。我见过一个数据分析工具类实例上挂着十几份中间结果DataFrame用户导出的pickle文件有80多MB后来在导出前加了一轮delattr清理文件直接降到15MB。再配合PyInstaller打包输出exe的体积肉眼可见地小了一截。这就是“对象瘦身→数据资源变小→打包产物变小”的完整链路。3.4 不要过度瘦身接口契约属性要保留delattr虽好但千万别把必要的属性也删了。一个类的对外契约属性比如配置项、主数据、回调函数这些是业务逻辑继续运行的前提。瘦身的边界应该是“只删除对象生命周期内不再需要的东西”而不是把属性删到只剩一个空壳。一个简单的判断标准删除这个属性之后如果对象的任何公共方法再次访问它都会出问题那它就不该被删。如果删除后只是让某个缓存失效或者让某个临时状态消失那就放心删。4. 可扩展性设计里delattr不是删除而是“恢复默认”4.1 插件系统卸载插件时清掉动态状态做插件化架构的人通常会很关心“插件可重复安装、可重复卸载”。动态属性是插件系统最容易出问题的点插件A往主对象上挂了一个ctx_on_start插件B也挂了一个ctx_on_start两个插件卸载的时候如果没有清理干净下次加载时就会互相干扰。这时候delattr能帮你显式收敛动态属性class Plugin: def __init__(self): self._handlers [] def install(self, manager): for event in (on_start, on_stop): manager.register(event, self.handle_event) setattr(self, ctx_ event, manager) def uninstall(self): for name in [n for n in vars(self) if n.startswith(ctx_)]: delattr(self, name)卸载时批量删除以ctx_开头的动态属性插件系统就能反复安装、卸载而不会残留上一次的上下文。这种写法比手动记一串属性名更稳健以后新增事件、新增ctx_属性uninstall方法不用跟着改。4.2 用delattr实现惰性缓存的“失效”很多类会通过__getattr__实现按需加载属性避免在初始化时把所有东西都准备好。配合delattr你还可以实现缓存失效class RemoteConfig: def __getattr__(self, name): if not name.startswith(config_): raise AttributeError(name) value load_from_remote(name) self.__dict__[name] value return value def refresh(self): for name in [n for n in vars(self) if n.startswith(config_)]: delattr(self, name)第一次访问obj.config_timeout时__getattr__去远程加载配置并缓存到实例字典。调用refresh()后缓存被delattr清掉下一次访问又会重新走__getattr__加载最新配置。这个场景里delattr不是“破坏”而是“恢复默认状态”。它让对象的属性集合保持动态可控既保留了惰性加载带来的性能优势又给了外部调用者一个干净的刷新入口。这种设计非常适合配置中心、权限校验、版本化数据这些需要定期更新的场景。4.3 装饰器里的一次性状态管理给类写装饰器时经常需要在方法执行期间临时记录一个状态但方法返回后又要立刻清理。比如避免同一个方法重入from functools import wraps def prevent_reentry(func): wraps(func) def wrapper(self, *args, **kwargs): flag_name _running_ func.__name__ if getattr(self, flag_name, False): raise RuntimeError(f{func.__name__} is already running) setattr(self, flag_name, True) try: return func(self, *args, **kwargs) finally: delattr(self, flag_name) return wrapper如果没有finally里的delattr即使方法执行结束这个临时标记也会一直留在对象上。下次调用getattr(self, flag_name, False)时会错误地认为方法还在运行。delattr在这里保证了对象在每次方法调用后都“回到原样”可扩展性自然更好。5. 用错delattr会踩的坑边界与规避方法5.1 删除不存在的属性会抛AttributeErrordelattr和直接访问不存在的属性一样都会抛AttributeErrord Downloader() try: delattr(d, not_exist) except AttributeError as e: print(e) # not_exist批量清理时建议用if name in vars(obj)判断或者用前面写的safe_delattr。不要直接依赖hasattr因为如果这个类实现了__getattr__hasattr可能会触发属性生成的副作用然后“有属性可删”但删完之后下一次访问又会生成造成清理无效的假象。5.2 property和描述符的删除行为如果一个属性的读取逻辑被property接管delattr并不会去删实例字典而是会找property对象有没有定义deleterclass A: property def x(self): return 1 a A() try: delattr(a, x) except AttributeError as e: print(e) # cant delete attribute如果定义了x.deleterdelattr(a, x)就会调用这个deleter。所以在使用delattr清理第三方库对象时要注意目标属性是不是描述符。如果是删除操作可能会触发额外逻辑而不是默默从字典里移除。5.3 __slots__类的属性删除使用__slots__的类没有实例字典属性由槽描述符管理。delattr可以删除槽位上的值但删除后访问该属性会抛AttributeError直到再次赋值class S: __slots__ (x,) s S() s.x 1 delattr(s, x) print(s.x) # AttributeError: x如果你在代码里对__slots__类的实例做动态属性清理要先确认这个属性是否存在、是否可以被删。而且__slots__类本身不支持动态添加新属性如果对象没有声明__dict__到__slots__里vars(obj)会报TypeError需要额外处理。5.4 别把delattr当成del objdelattr(obj, attr)是删除对象上的一个属性但并不会删除对象本身。一个对象能否被垃圾回收取决于它还有没有存活的引用。就算你把一个对象的所有属性都删光只要外部还有变量引用它它照样活在内存里。在某些“清理”代码里我看到有人写delattr(self, data)然后期望整个对象被回收。这是误解。如果真想减少内存占用要同时切断所有引用包括列表项、字典值、回调闭包等。delattr只负责把对象内部变干净不负责让对象消失。5.5 并发环境下的竞态多线程场景下一个线程正在读取obj.cache另一个线程执行delattr(obj, cache)读取方就会收到AttributeError。如果属性确实可能被并发删除读取方要用getattr(obj, cache, None)或者做好异常捕获。更推荐的做法是在对象的清理协议里增加锁保护但很多业务代码其实不需要考虑这么细知道有这个坑就够了。6. 附赠一个属性体检模板照着抄就行6.1 通用属性大小分析函数想快速定位“胖”对象可以用下面这个模板扫一遍import sys from types import ModuleType, FunctionType def scan_attrs(obj, depth0, seenNone): if depth 2: return if seen is None: seen set() if id(obj) in seen: return seen.add(id(obj)) if isinstance(obj, (ModuleType, FunctionType)): return try: attrs vars(obj) except TypeError: return if not attrs: return print( * depth f对象 {type(obj).__name__} 有 {len(attrs)} 个属性) for key, value in attrs.items(): size sys.getsizeof(value) print( * depth f- {key}: {type(value).__name__}, sys.getsizeof{size}) if depth 2: scan_attrs(value, depth 1, seen) class BigObject: def __init__(self): self.df list(range(10000)) self.session {token: x, history: list(range(1000))} self.ok True scan_attrs(BigObject())sys.getsizeof不会递归计算“属性里的属性”但它足够用于排序和定位。真要看完整内存占用可以用pympler库的asizeof.asizeof(obj)那个更准。6.2 批量清理模板当你已经确定了要清理的属性列表建议复制这个工具函数def safe_delattr(obj, name): if name in vars(obj): delattr(obj, name) def cleanup_attrs(obj, names): for name in names: safe_delattr(obj, name)如果清理的是动态前缀属性就扫描vars(obj)的键def cleanup_by_prefix(obj, prefix): for name in [n for n in vars(obj) if n.startswith(prefix)]: safe_delattr(obj, name)6.3 打包前的瘦身检查清单我自己的习惯是在准备打包发布前对项目里的核心类跑一遍以下检查所有实例属性是不是对象整个生命周期内都必须存在的大体积临时数据是否已经通过cleanup()清理缓存属性有没有失效机制没有的话是删掉还是加上序列化、多进程传参之前是否调用过清理协议打包过程中生成的pickle、json、缓存文件是不是已经重新生成过最小版本这套流程看起来很简单但真的很管用。尤其是项目交接的时候跑一遍属性体检往往能发现好几个历史遗留的动态属性。它们平时不影响功能却默默拖累内存和打包产物。把这些属性清理干净对象瘦了代码扩展起来也更安心。