好，这个问题属于那种平时不用没事，一旦要用就全是坑的典型。__reduce__这东西是 Python pickle 协议的核心钩子，但它设计的出发点跟大多数人想的完全不一样。

先给你泼盆冷水：__reduce__不是为了让你方便地序列化对象，而是为了让那些没法正常 pickle 的对象能被 pickle。这两个目标看着差不多，实际差远了。

1. __reduce__到底返回什么？

先看最基本的。__reduce__应该返回一个元组，最常见的形式是：

(callable, args[, state[, ...]])

pickle 的时候，它会把 callable(*args)作为重建对象的方式，然后用 state来恢复对象的 __dict__。

听起来很直白对吧？但陷阱就在这个 "callable" 上。

2. 陷阱一：callable 必须是可 pickle 的，而且得是全局可访问的

这是最容易翻车的地方。很多人这么写：

class MyClass:

def __init__(self, x):

self.x = x

def __reduce__(self):

return (self.__class__, (self.x,))

看起来没问题？跑一下试试。如果你的类定义在脚本顶层，确实没问题。但如果你的类是嵌套在某个函数里的、或者是动态创建的，self.__class__在 unpickle 的时候就找不到了。

更坑的是 lambda：

class BadIdea:

def __reduce__(self):

return (lambda: self.__class__(42), ()) # 爆炸预定

lambda 没法被 pickle，因为它是匿名的，pickle 找不到它的引用路径。你会得到一个 AttributeError，说找不到这个 lambda。

正确做法：确保 callable 是一个模块顶层的可导入函数或类。别玩花活。

3. 陷阱二：__getstate__和 __setstate__的微妙关系

很多人以为实现了 __reduce__就不用管 __getstate__了。错了。

__reduce__返回的第三个元素就是 state，这个 state 会传给 __setstate__（如果有的话）。但如果你同时定义了 __getstate__，pickle 的时候会用 __getstate__的结果覆盖掉你 __reduce__返回的 state。

这就导致了一个非常隐蔽的问题：

class Sneaky:

def __init__(self, data):

self.data = data

self.cache = {}

def __getstate__(self):

return {'data': self.data} # 故意不保存 cache

def __setstate__(self, state):

self.__dict__.update(state)

self.cache = {} # 重建空缓存

def __reduce__(self):

return (self.__class__, (self.data,), {'data': self.data, 'cache': self.cache})

# ↑ 这里的 cache 永远不会被用到，因为 __getstate__ 优先级更高

看到了吗？你在 __reduce__里精心构造的 state，被 __getstate__悄无声息地替换了。这俩东西的优先级是：__getstate__> __reduce__返回的 state。

4. 陷阱三：__reduce_ex__的存在意义

__reduce__还有一个大哥叫 __reduce_ex__。区别在于 __reduce_ex__接收一个 protocol 参数。

如果你只实现了 __reduce__，Python 会在所有协议版本下都调用它。但问题是，低版本的 pickle 协议（protocol 0, 1）不支持某些特性，比如 __newobj__。如果你在 __reduce__里用了高版本才有的特性，低版本 unpickle 就直接炸。

最佳实践：实现 __reduce_ex__而不是 __reduce__，根据 protocol 版本决定返回策略。

def __reduce_ex__(self, protocol):

if protocol >= 2:

return (self.__class__, (self.x,), self.__dict__)

else:

# 降级方案

return (self.__class__, (self.x,))

5. 陷阱四：循环引用的噩梦

如果你的对象有循环引用，普通的 pickle 能处理，因为 pickle 有 memo 机制记录已经序列化的对象。但如果你自己实现了 __reduce__，这个机制可能会被你绕过去。

class Node:

def __init__(self):

self.parent = None

self.children = []

def __reduce__(self):

# 手动构造序列化

return (self.__class__, (), {'parent': self.parent, 'children': self.children})

如果 self.parent指向另一个 Node，而那个 Node 的 children 又包含 self，你手动返回的这个 dict 会让 pickle 陷入无限递归——因为你在 __reduce__里已经把整个引用图展开了，pickle 的 memo 根本来不及记录。

解决方案：不要在 __reduce__里手动展开引用关系，交给 pickle 自己去处理。如果你必须干预，考虑用 copyreg的 _reconstructor或者 __reduce_ex__配合 __getstate__来控制哪些属性需要序列化。

6. 实战建议：什么时候该用 __reduce__

说了这么多坑，那到底什么时候该用？

当你有一个 C 扩展类型的对象，没法直接用 __dict__序列化时——比如 socket 对象、文件句柄，你需要告诉 pickle 如何重建这个对象。

当你的对象需要通过工厂函数重建时——比如单例模式、连接池对象。

当你想控制反序列化时的初始化逻辑时——比如跳过昂贵的 __init__计算。

其他情况，优先用 __getstate__/ __setstate__。这俩是专门为序列化设计的，语义清晰，坑少得多。

总结

问题

原因

解决

callable 不可 pickle

使用了局部函数/lambda

用模块顶层函数或类

state 被覆盖

__getstate__优先级更高

统一用一个，别混用

协议兼容性

低版本不支持新特性

用 __reduce_ex__判断协议版本

循环引用

手动展开破坏了 memo

让 pickle 自己处理引用关系

一句话：__reduce__是最后的手段，不是首选。能用 __getstate__解决的问题，别碰 __reduce__。

ITPub博客

reduce 与自定义对象序列化陷阱

最新文章

ITPub博客

__reduce__ 与自定义对象序列化陷阱

最新文章

reduce 与自定义对象序列化陷阱