__str__面向用户，控制print()和str()输出；__repr__面向开发者，控制repr()、交互式回显和调试日志输出；二者语义不同，必须分别实现且返回str类型。
直接说结论：用 __str__ 控制 print() 和 str() 的输出，面向用户；用 __repr__ 控制 repr()、交互式环境回显、日志调试输出，面向开发者——两者语义不同，不能只写一个凑合。
什么时候该实现 __str__
当你希望对象在被 print() 或转成字符串时，显示简洁、可读、带业务含义的内容。比如用户看到的订单摘要、日期格式化结果、配置项简要描述。
常见错误现象：print(user) 输出 <__main__.User object at 0x...>，说明没定义 __str__，或返回了 None（必须 return 字符串）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
__str__返回值必须是str类型，不能是int或None - 避免包含内存地址、类型名等技术细节
- 可复用
__repr__的逻辑，但要做简化，比如去掉引号、省略长字段
def __str__(self):
return f"订单#{self.order_id}（{self.status}，¥{self.total:.2f}）"
为什么 __repr__ 更重要，且必须能“被 eval”
在调试、日志、IPython/Jupyter 中，对象默认调用的是 __repr__。它应该做到：明确标识对象身份（类名 + 关键属性）、尽可能可重建（即 eval(repr(obj)) == obj 成立），至少是无歧义的。
容易踩的坑：
- 只写了
__str__，没写__repr__→ 日志里全是<xxx object at ...>，查问题效率极低 -
__repr__返回了中文或空格开头的字符串 → 导致eval()失败，虽不强制要求可 eval，但这是行业共识 - 漏掉关键字段（如 ID、状态），导致多个实例在日志中无法区分
def __repr__(self):
return f"Order(order_id={self.order_id!r}, status={self.status!r}, total={self.total!r})"
注意 !r 是格式化语法，等价于 repr()，自动加引号、转义，比手动拼接更安全。
__str__ 和 __repr__ 在容器里的行为差异
列表、字典等容器调用 __str__ 时，内部元素用的是 __str__；但调用 __repr__ 时（比如你在终端敲 orders 回车），所有元素都走 __repr__。
这意味着：如果你只实现了 __str__，那么 print([obj]) 看起来正常，但 [obj] 在交互式环境里仍显示为 [<...>]。
性能与兼容性提示：
-
__repr__不应太慢或触发副作用（比如查数据库），它可能被日志框架高频调用 - 若对象不可重建（如含文件句柄、网络连接），
__repr__应明确标注，例如FileReader(path='xxx', closed=False) - 第三方库（如
dataclasses）默认只生成__repr__，不会自动生成__str__
别依赖继承链自动 fallback
Python 不会在找不到 __str__ 时自动用 __repr__ 替代（虽然某些文档这么说，但实际行为是 fallback 到父类的 __str__，而 object.__str__ 就是那个难看的 <...>）。同样，__repr__ 缺失也不会用 __str__ 补。
所以最稳妥的做法是：两个都显式定义，哪怕 __str__ 只是包装一层 __repr__ 的简化版。
真正容易被忽略的点：很多人在写单元测试时用 assert str(obj) == "..."，却忘了检查 repr(obj) 是否也符合预期——尤其当对象用于断言失败消息或 pytest 的异常快照时，__repr__ 才是真正露脸的那个。
