默认异常无法被pickle是因为其未实现__reduce__或默认实现仅返回类和空元组，不保存实例字段；需手动定义__reduce__返回(callable, args)二元组，确保参数均可序列化，并注意父类构造签名兼容性。
为什么默认异常无法被 pickle
Python 的大多数内置异常（如 ValueError、TypeError）在反序列化时会丢失部分状态，尤其是当它们携带了非基本类型字段（比如自定义对象、闭包、线程局部变量等）时，pickle 会报 AttributeError: Can't pickle local object 或直接静默丢弃字段。根本原因是这些异常类没实现 __reduce__，或其默认实现只返回类和空参数元组，不包含实例字段。
手动实现 __reduce__ 的关键写法
要让自定义异常支持安全 pickle，必须显式定义 __reduce__ 方法，确保它返回一个可调用对象 + 参数元组，且所有参数都可被 pickle 序列化。
-
__reduce__必须返回二元组：(callable, args)，其中callable通常是类本身或工厂函数，args是重建实例所需的全部位置参数 - 避免在
args中传入不可 pickle 的对象（如 lambda、嵌套函数、模块级未命名对象） - 如果异常有额外属性（如
self.context、self.payload），必须显式包含进args，或通过__setstate__补充 - 推荐用
functools.partial包装构造逻辑，而不是闭包——前者可被 pickle，后者通常不行
示例：
import pickle
from functools import partial
<p>class MyError(Exception):
def <strong>init</strong>(self, message, code=None, context=None):
super().<strong>init</strong>(message)
self.code = code
self.context = context # 假设 context 是 dict 或其他可 pickle 类型</p><pre class="brush:php;toolbar:false;">def __reduce__(self):
# 返回：(构造器, (message, code, context))
return (partial(MyError, self.args[0]), (self.code, self.context))
继承内置异常时的兼容性陷阱
直接继承 Exception 没问题，但若继承像 ConnectionError 这类有特殊 __init__ 签名的子类，__reduce__ 返回的参数顺序必须严格匹配其父类构造逻辑，否则 unpickle 会抛 TypeError: __init__() takes X positional arguments but Y were given。
- 查清父类
__init__签名（用help(父类.__init__)或看源码），不要假设只有message - 若父类接受关键字参数（如
requests.exceptions.RequestException），__reduce__应返回(cls, (), kwargs)形式，即三元组 - 某些异常（如
OSError子类）内部依赖errno和strerror字段，仅靠重写__reduce__不够，还需确保__setstate__正确还原底层 C 层状态
测试 pickle 行为是否真正可靠
光能跑通 pickle.dumps() 不代表安全——必须验证反序列化后对象行为一致，尤其 args、__cause__、__traceback__ 是否保留。
- 用
pickle.loads(pickle.dumps(exc))后检查：type(new_exc) is type(exc)、new_exc.args == exc.args、getattr(new_exc, 'code', None) == getattr(exc, 'code', None) - 显式触发
raise新异常，确认堆栈和上下文无损（__traceback__在 unpickle 后默认为None，这是预期行为） - 在不同 Python 版本间测试（如 3.8 → 3.12），
__reduce__返回的 callable 若引用了模块内局部函数，可能因路径变化失效
真正麻烦的是那些带动态生成属性或弱引用字段的异常——它们没法靠 __reduce__ 完全还原，只能提前剥离或改用可序列化的替代结构。
