只用 pickle.HIGHEST_PROTOCOL 不够，必须配合对象结构改造和协议显式指定，否则性能提升几乎为零；协议5仅对含重复引用或循环引用的对象加速，纯嵌套结构无收益，且需显式传参才生效。
直接结论：只用 pickle.HIGHEST_PROTOCOL 不够，必须配合对象结构改造和协议显式指定，否则性能提升几乎为零。
为什么 pickle.HIGHEST_PROTOCOL 有时没用
Python 3.11 的 HIGHEST_PROTOCOL 是 5，但它默认不启用“带引用压缩的快速路径”——只有当对象图中存在重复引用（比如多个 list 共享同一个子 dict）时，协议 5 才会真正跳过重复序列化；而纯嵌套结构（如 10 万条独立字典组成的 list）依然走完整遍历。更关键的是，如果你在旧环境（如 Python 3.7）里没显式传参，pickle.dumps(obj) 实际跑的还是协议 3，比协议 5 慢 20% 以上。
常见错误现象：pickle.dumps(data) 耗时 642ms，加上 protocol=pickle.HIGHEST_PROTOCOL 后仍为 638ms——看似没变，其实是对象本身没触发协议 5 的优化条件。
- 务必显式写成
pickle.dumps(data, protocol=pickle.HIGHEST_PROTOCOL)，别依赖默认 - 检查运行环境：
print(pickle.HIGHEST_PROTOCOL)，Python 3.8+ 是 4，3.11 是 5，但某些容器镜像可能冻结了旧版本 - 协议 5 对循环引用、共享对象敏感，但对“扁平大 list”收益有限——这时该换方案，不是死磕协议
哪些对象结构会让 pickle 协议 5 失效
协议 5 的加速逻辑依赖于对象图中可复用的节点，一旦结构破坏这个前提，它就自动降级回慢速模式。
立即学习“Python免费学习笔记（深入）”；
- 含
__dict__循环引用的对象（如父子树节点互相持有对方引用），pickle 会切到安全但极慢的递归遍历模式 - 自定义类未实现
__getstate__，导致整个__dict__被无差别 dump，包括临时缓存、锁、文件句柄等不可序列化字段 - 大量小对象（如 50 万个
dataclass实例），每个实例都带独立__dict__，内存碎片+解释器调用开销压倒协议优化
实操建议：用 sys.getsizeof() 粗略看单个对象大小，如果平均 10 万，优先考虑转成 list of tuple 或预打包为 array.array。
比升级协议更有效的三件事
协议只是底层编码方式，真正卡住速度的往往是上层数据组织。实测中，结构调整带来的提速常达 3–5 倍，远超协议切换的 20%。
- 把嵌套 dict 改成 tuple + 预定义 schema：例如
{"id": 123, "name": "a", "score": 95.5}→(123, "a", 95.5)，序列化体积减半，pickle 遍历快一倍 - 用
__slots__替代__dict__：类声明加__slots__ = ("id", "name", "score")，避免 pickle 为每个实例生成冗余字典头 - 提前过滤掉非必要字段：在
__getstate__里只返回核心数据，例如删掉self._cache、self._lock等运行时状态
示例：
class Record:
__slots__ = ("id", "name", "score")
def __init__(self, id, name, score):
self.id = id
self.name = name
self.score = score
def __getstate__(self):
return (self.id, self.name, self.score) # 返回 tuple，不是 dict
这样序列化的不再是带键名的字典流，而是紧凑的二进制元组，协议 5 能直接映射到 C 层 memcpy。
真正容易被忽略的点：协议版本只是“允许怎么编”，而对象形状决定“有没有机会编得快”。一堆不可变 tuple 比一个巨型嵌套 dict 更适配 pickle 的底层机制——这不是玄学，是 CPython 序列化器对连续内存块的硬编码优化路径。
