自定义异常需同时重写 __str__ 和 __repr__：__str__ 返回用户友好的简明描述，__repr__ 返回可重建对象的合法表达式，避免副作用、异常和性能开销，并通过双重测试校验。
自定义异常的 __str__ 和 __repr__ 方法
Python 异常默认只继承 BaseException 的 
__repr__，输出就是参数元组（如 MyError('msg') 显示为 "('msg',)"）。要控制格式，必须显式重写这两个方法。
常见错误是只改 __str__ 忘了 __repr__，导致日志里或交互式环境（如 IPython）中仍看到难读的原始形式；或者在 __repr__ 里返回非合法 Python 表达式（比如没加引号、含换行），破坏调试体验。
实操建议：
-
__str__返回用户友好的简明描述，不带类型名和括号，比如"文件 '/tmp/x' 不存在" -
__repr__应尽量返回可重建对象的表达式，至少包含异常类名和关键参数，用repr()包裹字符串字段，比如"FileNotFoundError('/tmp/x')" - 避免在
__repr__中调用可能抛异常或耗时的操作（如读文件、网络请求）
继承内置异常时保留原行为再增强
直接继承 ValueError 或 IOError 等，不代表自动获得其 __str__ 的语义。这些内置异常的 __str__ 是基于 args 动态生成的，但你一旦重写，就得自己处理所有参数逻辑。
使用场景：想复用内置异常语义（比如 KeyError 默认把 key 加单引号），又想追加上下文信息。
实操建议：
- 调用父类
super().__str__()获取基础描述，再拼接额外字段，例如：return super().__str__() + f" (context={self.context})" - 若需兼容原有
repr格式（如KeyError('foo')），__repr__中应显式构造类似字符串，不要依赖super().__repr__()—— 因为父类实现可能不暴露你新增的属性 - 注意
args是只读元组，修改它不会影响父类方法输出；新增属性（如self.timestamp）必须在__init__中赋值，并在__repr__中手动包含
避免在 __str__/__repr__ 中触发新异常
格式化方法被日志系统、调试器、print() 隐式调用，一旦内部出错（如访问未初始化属性、格式化失败），会抛出 RecursionError 或掩盖原始异常，造成“异常中的异常”，极难排查。
典型错误现象：抛出自定义异常后，控制台显示 RecursionError: maximum recursion depth exceeded while calling a Python object，而不是你的异常内容。
实操建议：
- 所有字段访问前加
getattr(self, 'field', 'N/A')或用hasattr()防御 - 字符串格式化统一用
f"{value!r}"或str(value)，避免.format()或%可能引发的TypeError - 不在这些方法中做 I/O、锁操作、或调用外部库函数
日志与调试场景下的实际表现差异
logging.exception() 默认调用 exc_info 并打印 __str__，而 logging.debug('%r', exc) 打印的是 __repr__。Jupyter 或 pdb 中输入 exc 回车，也触发 __repr__；但 print(exc) 触发 __str__。
性能影响：如果 __repr__ 构造复杂字符串（比如 dump 整个 traceback 或对象树），在高频日志场景下会拖慢性能，且多数时候并不需要完整信息。
实操建议：
- 生产环境日志优先依赖
__str__，确保简洁；调试专用字段（如self.trace_id）只出现在__repr__中 - 若异常携带大量上下文（如 HTTP 请求体），
__repr__中应截断或标记省略，例如f"... {len(self.body)} bytes" - 测试时用
assert str(MyError('x')) == "x"和assert repr(MyError('x')) == "MyError('x')"双重校验，防止重构破坏格式
真正麻烦的不是写这两个方法，而是确保它们在所有调用路径下都稳定——尤其当异常被序列化（如传给 multiprocessing 或 sentry sdk）时，__repr__ 可能被意外求值，任何隐式副作用都会放大问题。
