遇到python疑难bug应先定位根源：用logging替代print以捕获上下文，善用breakpoint()和post-mortem调试，检查对象真实类型与状态，用tracemalloc和faulthandler排查内存泄漏与c扩展崩溃。
遇到 Python 疑难 bug，别急着改代码，先定位根源。核心思路是：让问题“显形”——缩小范围、捕获异常上下文、观察运行时状态。
用 logging 替代 print，带上下文输出
print 只能看值，logging 能记录时间、模块、行号、函数名，且可开关、分级、输出到文件。疑难 bug 往往出现在异步、多线程或深层调用中，静态 print 容易漏掉关键路径。
建议：
- 在关键函数入口加
logger.debug("enter func_x, args=%r", args) - 在可能出错的语句前后加日志，比如
logger.debug("before db query, user_id=%s", user_id) - 配置日志格式含
%(funcName)s:%(lineno)d，快速定位到具体行 - 临时把日志级别设为 DEBUG，复现问题后切回 WARNING 查看完整链路
善用 breakpoint() 和 post-mortem 调试
不是所有 bug 都能靠断点复现。对偶发、超时、内存暴涨类问题，等它崩溃后再进调试更高效。
立即学习“Python免费学习笔记（深入）”；
做法：
- 启动脚本时加
-X dev或设置export PYTHONFAULTHANDLER=1，让崩溃时自动打印 traceback 和当前帧变量 - 捕获异常后手动进入 post-mortem：
import pdb; pdb.post_mortem()（放在 except 块末尾） - 在可疑函数开头加
breakpoint()，运行时输入p locals()、u（up）、d（down）查看调用栈和变量
检查对象真实类型与状态，别信变量名
很多 bug 来自“我以为它是 list，其实它是 None 或 generator”、“我以为它已初始化，其实被 early return 跳过了”。Python 动态类型让这类问题隐蔽。
排查技巧：
- 用
type(obj)和isinstance(obj, expected_type)双重确认，尤其注意None、False、空字符串、空列表的边界情况 - 对容器类对象，打印
len(obj)、list(obj)（谨慎用于 generator）、hasattr(obj, '__iter__') - 怀疑对象被意外修改？在关键位置加
id(obj)对比，确认是否同一对象
用 tracemalloc 定位内存泄漏，用 faulthandler 捕获 C 扩展崩溃
当程序越跑越慢、内存持续上涨，或直接 segfault，说明问题可能不在纯 Python 层。
实操步骤：
- 内存问题：启动时加
import tracemalloc; tracemalloc.start()，出问题后调用snapshot = tracemalloc.take_snapshot()，再用snapshot.statistics('lineno')找出分配最多内存的代码行 - C 扩展崩溃（如 numpy、pandas、cryptography 相关）：加
import faulthandler; faulthandler.enable()，崩溃时会输出 C 栈帧，配合 core dump 分析更准 - 怀疑第三方库行为异常？用
pip show package_name确认版本，查其 issue 页面，有时是已知 bug
