如果你写过 Python一定遇到过这类需求程序跑完把内存里的字典、列表或者某个自定义类实例保存到磁盘下次启动再原封不动读回来。Python 为此内置了一个序列化模块叫 pickle标题说得很直白——Pickle 是 Python 内置的序列化模块用于把 Python 对象字典、列表、自定义类实例等转换成字节流也就是俗称的“腌制”。今天这篇不打算只念官方文档我想从一个实际用 pickle 干过几年活的角度把“腌制”背后从原理到坑、从协议版本到安全红线的事一次讲明白。我最早接触 pickle 是在某个数据分析项目的中间结果缓存里。当时数据是若干嵌套很深的字典存成文本完全不现实用 JSON 又老要处理 datetime 之类不能直接序列化的类型。换用 pickle 之后整个保存和恢复变得“无脑”也因此让我养成了一个坏习惯碰到任何持久化需求都先甩一个 pickle。后来被坑过也踩过雷才明白pickle 用起来只是“看起来简单”背后有一堆版本、兼容性、安全、性能的取舍。这篇就按我自己的使用脉络来聊省去不必要的理论铺垫直接落到能实操的层面。1. Pickle 的出身从内存到磁盘的“脱水封装”1.1 为什么需要序列化程序世界里的“保鲜”先把大背景说清楚。Python 进程跑起来之后大量对象是活在内存堆里的列表的索引、字典的哈希表、类实例的属性引用关系全部是进程内的临时状态。一旦进程结束内存释放数据就没了。但实际需求往往是想“过一会儿再回来”训练好的模型明天接着用爬到一半的网页数据下次继续处理或者干脆想把阶段性结果分享给同事的脚本加载。这时就需要一种机制把内存对象“定格”下来保存成稳定的字节序列等之后再“解冻”还原。这个过程叫序列化serialization英文里也叫 marshalling反向操作则叫反序列化。序列化听起来抽象拿生活里的类比就简单了新鲜水果直接运输容易坏、占体积于是做成干果、罐头或者冻干吃的时候再泡发复原。pickle 对 Python 对象干的基本是同一件事——它把对象的类型信息、属性、内部结构统统打包成字节串下次 load 的时候再按“配方”原样拼回来。1.2 pickle 和“腌制”的命名真相pickle 这个名字本身就是一种“保鲜”暗示。Python 对象的“腌制”过程就是从 Python 对象变成 bytesunpickling 则把 bytes 变回原来的 Python 对象。很多人第一次看到pickle.dumps(obj)返回的一堆乱码时都会愣一下因为这些字节不是给人读的而是给 Python 运行时读的。一个关键认知是pickle 并不是把 Python 对象转成文本而是转成一种图描述。它记录了对象的类、属性、嵌套关系甚至对象之间的共享引用。比如一个列表里有两个元素指向同一个对象pickle 在序列化时会保留这种共享引用关系load 回来以后两个元素依然指向同一个对象而不是变成两个拷贝。这是 JSON 很难做到的事也是 pickle 在对象持久化场景里无法被轻易替代的原因之一。1.3 pickle 天生适合解决的事情结合我自己的观察pickle 真正好用的场景通常集中在四类程序间的中间结果缓存。进程 A 跑出一个临时对象直接 pickle 丢文件进程 B 读完继续用省去重新计算。机器学习模型的保存。很多经典算法的 sklearn 模型本身就是 Python 对象pickle 是官方推荐的落盘方式之一。需要保留引用结构和自定义类型的场景。比如嵌套了 datetime、自定义类、对象图较为复杂用 pickle 能一次性还原成原样。本地可信数据的快速存取。对读写速度要求高、纠错要求低且数据来源完全由自己掌控。但这些“天生适合”都有一个共同前提数据来源可控。这一点后面会专门说在 pickle 的安全问题里它是致命的。2. 基础操作拆解dumps、loads、dump、load 四件套2.1 文件级持久化dump 和 loadpickle 最标准的用法是配合文件对象使用。一个最简单的例子import pickle data { name: demo, scores: [88, 92, 79], nested: {enabled: True, note: hello}, } with open(data.pkl, wb) as f: pickle.dump(data, f)读回来with open(data.pkl, rb) as f: restored pickle.load(f) print(restored)有两个点容易出错。第一文件打开方式必须用二进制模式wb和rb如果只写w或rpickle 会直接报TypeError或产生不可预期的结果。第二pickle.dump的第二个参数是文件对象而不是文件名这个跟json.dump一致但新手常记成传路径。文件级持久化适合一次性保存大量对象。你可以在一个文件里连续 dump 多个对象之后按顺序 load 出来with open(multi.pkl, wb) as f: pickle.dump({first: 1}, f) pickle.dump([a, b], f) with open(multi.pkl, rb) as f: a pickle.load(f) b pickle.load(f)这背后的机制是 pickle 在 dump 时会把每个对象独立编码进字节流load 时从当前位置开始解析一个完整的对象。需要注意的是多个 dump 之间并没有“记录长度”之类的标记所以 load 的顺序必须和 dump 的顺序一致跳着读或重复读都会出问题。2.2 内存序列化dumps 和 loads如果不想落盘只在内存里转换就用pickle.dumps和pickle.loads。它们接受一个对象返回 bytes或者接受 bytes返回还原后的对象。import pickle data {x: 1, y: [1, 2, 3]} blob pickle.dumps(data) print(type(blob)) # class bytes print(len(blob)) # 字节长度 restored pickle.loads(blob) print(restored data) # True内存态序列化的典型用途是跨网络传输对象、写入数据库的 BLOB 字段或者在并行进程之间传递数据。比如某些分布式任务队列任务参数就可以通过 pickle 序列化后塞进消息队列。还有一个常见场景是把 pickle 的 bytes 数据经过压缩后再存储。这看起来多绕了一层但实际效果很好因为 pickle 字节流里包含大量结构信息和重复的对象描述压缩率通常不错。比如配合zlibimport pickle import zlib data {rows: [i for i in range(1000)]} compressed zlib.compress(pickle.dumps(data)) decompressed pickle.loads(zlib.decompress(compressed))2.3 还原的不只是“长得像”的对象而是引用关系我在项目里见过不止一次困惑pickle.loads 之后拿到的对象和原来的对象类型一样但为什么is判断总是不一样这是因为 pickle 的还原过程是“重新构造一个对象”它不等于原对象本身。如果你需要一个“等值但不同身份”的对象这完全没问题但如果有人用is做单例判断或者依赖模块级对象的全局唯一性pickle 还原就容易引发隐蔽 bug。举个极端例子模块里有一个全局配置单例# config.py CONFIG {mode: prod, debug: False}如果某个对象在序列化时直接引用了CONFIGpickle 在还原时会怎么做它会认为这是一个模块属性引用并在主模块加载后通过__import__机制重新找到config.CONFIG这个对象来解引用。也就是说这时候还原出来的是全局对象本身而不是新建一份拷贝。所以 pickle 处理模块级引用和处理普通实例属性的策略完全不同行为细节容易出问题。3. 版本协议是最大暗礁不同 pickle 协议的兼容性与行为差异3.1 从协议 0 到协议 5pickle 的字节格式一直在变很多人以为 pickle 格式只有一种其实它有多个“协议版本”。从最早 Python 1.4 时代的协议 0到后来为了效率出现的协议 1、Python 2.3 的协议 2、Python 3.0 的协议 3、Python 3.4 的协议 4、Python 3.8 的协议 5。区别不在序列化出来的“内容”而在编码方式和性能上。比如协议 0 是人类勉强能看的 ASCII 文本体积大、速度慢协议 1 是二进制格式协议 2 开始支持新式类的更多特性协议 3 是 Python 3 专用的默认协议协议 4 增加了对大型对象的优化和更多内置类型支持协议 5 引入了 out-of-band data在处理大 buffer 时能显著减少内存拷贝。默认情况下pickle.dump使用当前 Python 版本兼容的默认协议。Python 3.8 的默认协议是 4协议 5 需要显式指定protocol5。如果我在明确知道环境版本的情况下通常不会依赖默认值而是直接给参数避免换版本后格式变化引发意外。with open(data.pkl, wb) as f: pickle.dump(data, f, protocol4)3.2 兼容性矩阵高版本能不能读低版本反过来说不可以pickle 的协议版本设计有向后兼容性较新版本的 Python 解释器可以读取用旧协议版本写成的 pickle 文件因为这个原因正常情况下用 Python 3.8 去 load 一个用 Python 2.x 以协议 2 写入的文件是可以的只要里面序列化的类型在当前环境里能正常导入。反过来就不成立用低版本 Python 去读高版本协议写出的文件会报ValueError: unsupported pickle protocol。这带来一个最重要的项目教训如果你的 pickle 文件要跨 Python 版本长期保存千万不要想都不想就用默认协议。比如一个团队有成员还在跑 Python 3.6另一个成员用了 Python 3.8 默认的协议 4 写文件Python 3.6 是能读的。但如果 Python 3.8 显式用了协议 5Python 3.6 就读不了。更棘手的兼容性问题是类定义的变迁。pickle 存储对象时会把类所在的模块和类名记录进去load 时通过import找到这个类再调用它来恢复实例。如果你的类从一个模块挪到了另一个模块或者类名改了老 pickle 文件直接 load 会报ModuleNotFoundError或AttributeError——这是 pickle 持久化里最高频的坑之一。后面安全章节会再谈这个风险。为了降低这种风险我习惯在一个项目里固定一个“序列化协议约定”类似锁文件一样写进开发文档。凡是需要长期保存的 pickle 文件统一指定protocol4防止有人用更新版本写出低版本环境读不了的文件。3.3 pickler 到底在“记录”对象的什么记住你离不开 import理解协议版本的差异本质上是理解 pickle 的“引用 vs 复制”策略。pickle 并不会把目标类的代码也一起序列化。它只序列化对象的状态遇到类对象时记录的是(module, qualname)引用。这意味着在 unpickle 那一刻运行环境里必须存在与被引用对象同名的可导入类。因此一个实用建议是把 pickle 文件视为“二进制快照 代码依赖”的组合而不是完全自包含的文件。别人拿到你的 pickle必须同时拥有你的模块代码否则即使有 pickle 也还原不出来。这个特点恰恰是它跟很多自包含格式最大的不同。4. 危险的红线为什么不能随便用 pickle 加载不受信任的数据4.1 安全风险的本质pickle 不只是“解码字节流”在讲完基础操作之后一定要马上把安全话题摆出来因为这是 pickle 所有优点背后的一个巨大陷阱。pickle 的还原流程本质上是一套“可以执行任意代码”的字节码解释器。怎么理解pickle 文件中不仅包含数据值还包含操作指令。pickle.load在解析字节流时会逐个执行这些指令来重建对象比如“新建一个对象”“设置属性”“调用某个函数”。问题在于某些指令允许调用可调用对象如果攻击者构造了一个恶意的 pickle 文件文件里存放的指令就可能调用到系统命令执行函数。其实没必要把 pickle 当成“数据格式”来看待最好用“执行代码”来对待它。pickle 的加载过程在安全意义上接近于一个明显不安全的eval。你对一份从不安全来源拿到的 pickle 文件执行pickle.load和把文件内容当作代码执行几乎没有本质差别。4.2 风险演示之外的安全边界我不打算在文章里贴出真正可执行恶意 payload 的完整代码因为这个信息本身在社区里已经被反复公开而且我们更要讨论的是防御原则。简单说一个恶意 pickle 的构造原理通常会利用__reduce__或类似机制在对象重建时触发可执行逻辑从而影响目标机器。你需要记住的不是构造方式而是决策模型绝对不要pickle.load来自不可信来源的数据包括未经验证的外部文件、网络下载内容、用户上传文件、邮件附件。即使是“看上去无害”的 pickle 文件只要来历不明就按恶意代码对待。如果业务需求是接收不可信数据应该先考虑 json、csv 等无执行能力的格式或者对内容做严格校验再决定是否可以进入 pickle 解析流程。我在实践中会直接把“能接触到 pickled 数据的用户”视作“能执行代码的用户”。这不是危言耸听。对一个暴露在外网的文件上传接口如果上传的 pickle 文件没做隔离处理就被人 load那后果和被人拿了一个 shell 写入点没什么两样。4.3 Linux/容器环境里如何缓解风险尽管“不要加载不受信任的 pickle”是最高原则但有些系统架构里确实绕不开比如旧项目的缓存中间层就是 pickle 序列化暂时改不掉。这时候至少要做几层防护数据源隔离把 pickle 文件存放在权限受控的目录确保只有可信进程能读写。进程沙箱如果无法避免解析外部 pickle把它放在低权限容器或独立进程中运行让攻击者即使拿到代码执行能力也无法直接访问核心系统。签名校验在保存 pickle 时附上 HMAC 签名加载前先校验签名是否匹配。这个方法能防篡改和伪造但前提是你的签名密钥很安全。import hashlib import hmac import pickle SECRET breplace-with-real-secret def sign_pickle(obj): blob pickle.dumps(obj) digest hmac.new(SECRET, blob, hashlib.sha256).hexdigest() return blob, digest def load_signed(blob, digest): expect hmac.new(SECRET, blob, hashlib.sha256).hexdigest() if not hmac.compare_digest(expect, digest): raise ValueError(pickle signature mismatch) return pickle.loads(blob)签名校验只是基础防线不能替代对数据源的信任评估。如果数据本身恶意但来源可信签名只会让伪造变成“不可行”拦不住真正来源方本身的行为。4.4 别踩“看起来安全”的变体坑我还要提醒另一种情况有些人会用一个简化版的RestrictedUnpickler或者用find_class限制可导入的模块以为这样就能让 pickle 安全。这种思路有一定缓解效果但远做不到绝对安全。pickle 的字节码指令比多数人想象的丰富只靠黑名单或限制导入类并不能兜住所有利用面。只要你能写一个具备任意代码执行能力的 pickle当前的限制策略就可能被绕过。所以我把这类“加固方案”定位成防御纵深的一环而不是核心信任边界。5. 替代方案选型json、shelve、dill、专用格式怎么选5.1 json vs pickle绝大多数场景的第一选择当数据主要是字典、列表、字符串、数字、布尔值这些基础类型时我强烈建议优先考虑json而不是 pickle。理由首先就是安全json 不包含任何一种可执行指令解析它顶多产生 JSONDecodeError不会变成代码执行。其次是可读性和跨语言性json 文件用文本编辑器能看被其他编程语言读取也没负担。但 json 的弱点也明显只支持基础类型包含 datetime、Decimal、自定义类实例、集合对象时会大概率报TypeError。如果数据里有这些类型要么自己写一套 encode/decode 转换逻辑要么升级成兼容更多类型的方案。举一个我经常用的场景配置文件的读取。配置一般是基础类型组合根本不需要 pickle直接 json.load 即可。只有当我需要序列化类实例、复杂对象图或 numpy 数组时才切换到更专门的格式。5.2 shelve适合天然以“字典”形态存在的数据shelve可以看作 pickle 的“字典形态”封装它把对象按 key 存储在一个底层数据库文件里value 仍然用 pickle 编码。它最大的特点是使用起来像操作普通 dict而且按 key 读取时只会加载对应 value不会一口气把整个文件读完。import shelve with shelve.open(mydata.db) as db: db[users] {a: 1} db[config] [1, 2, 3]shelve 的底层文件格式依赖实现跟 gdbm、dbm 不同版本之间可能会不兼容而且同样是基于 pickle 序列化 value所以安全边界和 pickle 相同不应存放不可信输入。它适合做轻量级本地缓存和中小规模应用配置但多进程同时写同一 shelve 文件时要特别谨慎锁控制不好会损坏数据。5.3 机器学习场景别把所有东西都硬塞给 pickle在机器学习项目中pickle 确实是常用工具比如用 joblib 或者直接 pickle 保存 sklearn 模型。但有一点必须区分pickle 适合保存“Python 对象快照”却不适合当作模型发布的唯一格式。最典型的问题是版本漂移。模型在一个旧版本的库中被 pickle新版本库的类结构发生变化后load 模型可能报错或产生行为异常。为此机器学习社区逐渐喜欢用统一的格式来保存模型权重和结构TensorFlow 的 SavedModel、PyTorch 的 state_dict 都是更可移植的选择。这类格式保存的是符号图和参数而不是对某个 Python 类定义的引用部署时才更稳定。如果是中间实验记录pickle 十分便捷如果是需要长期部署、跨团队共享、或跨语言调用的模型我会优先用领域内标准格式而不是直接 pickle。5.4 选型参考表我整理了一个粗略的选型参考表方便你在技术方案评审时直接拿来用方案支持类型安全性可读性跨语言典型场景picklePython 任意可递归对象不安全等同代码执行二进制乱码仅 Python本地可信对象的快速持久化json基础类型及组合安全文本可读优秀配置、API、跨语言数据交换shelve依赖 pickle同 pickle底层不可读仅 Python字典式缓存、小型本地数据库joblib多数模型对象同 pickle二进制弱sklearn 模型持久化dillpickle 的超集同 pickle二进制仅 Python序列化 lambda、局部函数等这张表想说明的核心是只有当“Python 对象图还原”这个需求足够强烈而且数据来源完全可控时pickle 才是合理选择。否则优先考虑更安全、更通用的方案省下来的隐患处理成本可能比序列化性能收益高得多。6. 那些年我踩过的 pickle 坑重构、递归、压缩与状态恢复6.1 类一旦重构老 pickle 就可能变成定时炸弹几年前我维护过一个项目某个自定义类最初放在utils/models.py里后来为了目录整洁被移到了core/models.py。旧 pickle 文件里记录了utils.models.MyClass而新环境里这个类已经不存在。结果系统升级后一批线上缓存文件变成了不可读的死数据。排查过程不算复杂但损失已经造成。从那以后我明白一件事pickle 不是数据库迁移工具它没有办法自动适配你的代码变化。想要 pickle 文件活得久就要让类结构尽量保持稳定实在要变就要同时考虑数据迁移方案。一个可落地的做法是给被 pickle 的类维护一个版本字段class MyRecord: __version__ 2 def __init__(self, name, score): self.name name self.score scoreload 出来后检查版本不匹配就执行老版本到新版本的数据转换。但要注意pickle 在还原实例时不会调用__init__而是通过特殊协议直接设置__dict__或调用__setstate__所以版本迁移逻辑要写在显式的地方。6.2 大对象压缩直接压缩文件对象是更好的姿势用 pickle 保存大的 pandas DataFrame 或嵌套字典时裸文件会大得吓人。一个常见错误是先把 pickle.dumps 出来的 bytes 内存压缩再写盘这在小文件上没多大感觉但大对象转换过程会同时占用大量内存而且多了一次内存拷贝。更优雅的做法是包装文件对象让 pickle 边序列化边压缩。标准库gzip、bz2、lzma都支持传入模式参数直接把压缩后的内容落到磁盘读取时同样用对应解压函数包装import gzip import pickle with gzip.open(data.pkl.gz, wb) as f: pickle.dump({big: list(range(1000000))}, f) with gzip.open(data.pkl.gz, rb) as f: data pickle.load(f)这种方法显得干净而且对大对象特别友好。压缩级别和底层算法可以按数据类型调文本类数据用 gzip 往往效果就很好数值型数组用 lzma 或 zstd 有时压缩率更佳。我个人的经验是在性能和压缩率之间对 pickle 这类结构数据gzip 的默认级别通常够用没必要为了再省几个百分点付出成倍的解压时间。6.3 递归引用和不可 pickle 的对象pickle 无法处理所有 Python 对象。下面这几类我在实际项目里都遇到过lambda 函数。它本质是匿名局部函数信息不足pickle 无法还原。生成器、迭代器。它们往往依赖运行时状态无法序列化。局部类。定义在函数内部的类qualname 带函数名还原时几乎不可能自动导入。文件对象、套接字、线程锁等运行时资源。它们可能包含操作系统句柄必须单独设计保存方案。某些第三方库的内部对象比如部分 GUI 组件。比如说如果你的数据字典里不小心混进了一个socket.socket或threading.Lock执行pickle.dumps会抛出TypeError: cannot pickle _io.BufferedWriter object而且调用栈很难一眼看出是哪个键惹的祸。我在处理这类问题时会先把对象的类型逐一打印出来找出不可 pickle 的类型或者是写一个递归检查函数在持久化前快速排查import pickle from types import GeneratorType def inspect_unpicklable(obj, pathroot): try: pickle.dumps(obj) return [] except Exception as exc: problems [] if isinstance(obj, dict): for k, v in obj.items(): problems.extend(inspect_unpicklable(v, f{path}.{k})) elif isinstance(obj, (list, tuple, set)): for i, item in enumerate(obj): problems.extend(inspect_unpicklable(item, f{path}[{i}])) else: problems.append((path, type(obj), str(exc))) return problems这个思路不复杂但在调试一些多层嵌套数据结构时非常有效。它的原理是层层深入到每一个子对象里尝试 pickle把不能处理的对象精确定位出来省去肉眼扫数万条记录的麻烦。6.4getstate和setstate控制还原过程的“外科手术”如果一个对象确实有无法序列化的字段但又必须要保存可以用__getstate__和__setstate__做定制。这两个方法是 pickle 协议的官方扩展点在 dump 时如果对象定义了__getstate__pickle 会调用它获取状态在 load 时如果有__setstate__则用它来恢复状态。一个常见的场景是类里持有文件句柄但文件句柄本身没有意义保存时真正需要的是文件路径加载后再重新打开文件。class FileHolder: def __init__(self, path): self.path path self._handle open(path, r) def __getstate__(self): state self.__dict__.copy() state[_handle] None # 句柄不序列化 return state def __setstate__(self, state): self.__dict__.update(state) self._handle open(self.path, r)这样既保持了对象外部接口不变又绕开了无法序列化的字段。需要注意的是__getstate__的返回值类型不一定要是字典也可以是元组之类的容器pickle 会原样记录并在还原时传给__setstate__。但如果两者不一致很容易产生隐蔽的状态错乱所以我自己会保持两边严格对称。结合__reduce__的进阶技巧pickle 甚至可以实现自定义的构造逻辑在对象还原时调用特定的工厂函数。这类能力在某些框架集成里非常有用但也是对安全风险影响最大的入口。越强的定制能力越要保持 “数据来源可信”的底线。最后再分享一个我自己长期在用的细节写 pickle 持久化相关代码时一定会把protocol参数写显式并且给待持久化类配置版本号在这两层之上再用签名校验。这样也许损失了一点“随手写”的便利但换来的是长线项目在迁移、升级、安全加固时能少踩很多隐形的坑。希望这篇围绕 pickle 的实战梳理能帮你把边界理清楚在需要使用它的地方放心使用在不该使用的地方及时换手。