traceback.print_exc() 默认只输出最后一层异常，因其仅打印当前活跃异常且不自动展开异常链；需显式传入 limit=None 和 chain=True 才能显示完整 traceback。
为什么 traceback.print_exc() 有时只输出最后一层异常？
默认情况下，traceback.print_exc() 只打印当前活跃的异常（即 sys.exc_info() 返回的那个），如果异常被多次捕获再抛出（比如在 except 块里用 raise 重新抛出），原始调用栈可能被截断。Python 3 默认启用异常链（__cause__ / __context__），但 print_exc() 不自动展开链式异常，导致你看到的只是“最新一层”。
- 若想看到从最外层入口函数开始的完整路径，必须显式传入
limit=None和chain=True -
chain=True（默认值）会递归打印所有关联异常（如raise new_exc from old_exc场景） -
limit=None确保不限制帧数——否则默认只打 100 层，深层递归或复杂框架调用容易被截断
如何在自定义异常类中触发完整 traceback？
类本身不控制 traceback 输出；真正起作用的是你捕获并打印异常的位置。但常见误区是：在类的 __init__ 或方法里直接调用 traceback.print_exc()，此时往往没有异常上下文（sys.exc_info() 为空），结果什么也不输出。
- 必须在
except块内调用，且该块确实捕获到了异常 - 不要在类方法里“盲目”加
traceback.print_exc()，除非你明确知道此刻有异常待处理 - 若想让类自动记录 traceback，应在实例化或方法失败后，由调用方负责捕获和打印
try:
some_risky_operation()
except Exception as e:
import traceback
traceback.print_exc(limit=None, chain=True) # ← 关键参数怎样把完整 traceback 写入日志而非打印到终端？
直接用 logging.exception() 是最简方案，它内部已设置 limit=None 和 chain=True，且自动附加 ERROR 级别和消息前缀。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
logging.exception("Something went wrong")会输出错误消息 + 完整 traceback - 若需更精细控制（比如写入特定文件、过滤敏感信息），可用
traceback.format_exc()获取字符串再处理 -
format_exc(limit=None, chain=True)返回 str，可拼接、截断、加密或发给监控系统
import logging
import traceback
<p>try:
1/0
except ZeroDivisionError:
logging.exception("Caught division error") # ← 推荐使用 traceback.print_exception() 的典型场景
当你需要分离异常类型、值、traceback 对象（比如从 sys.exc_info() 手动获取），或者要重定向到特定 stream（如 StringIO、文件对象），就得用 print_exception()。
立即学习“Python免费学习笔记（深入）”；
- 参数顺序固定：
type, value, tb，三者都来自sys.exc_info() - 务必传
chain=True，否则隐式异常链（如__context__）不会显示 - stream 参数决定输出位置，默认是
sys.stderr，可设为open("debug.log", "a")
实际中极少需要手动拆解这三元组——除非你在写调试工具或异常代理中间件。多数情况，print_exc() 或 logging.exception() 更安全、不易漏参数。
