pdb 不适合生产环境调试——它会阻塞线程、暴露栈帧、无访问控制，Ctrl+C 可能致服务卡顿或崩溃；应改用日志、指标、快照、注入诊断等非交互方式。
用 pdb 在生产环境打补丁？别试了
直接说结论：pdb 不适合生产环境调试——它会阻塞线程、暴露栈帧、没有访问控制，一次 Ctrl+C 就可能让服务卡住几秒甚至挂掉。真出问题时，你没法在用户请求里插个断点再单步。
替代思路不是“换个调试器”，而是把“调试”这件事拆开：日志查路径、指标看瓶颈、快照抓现场、注入式诊断做验证。
-
pdb.set_trace()和breakpoint()都得从生产代码里彻底删掉，CI 流水线可以加检查（比如 grep -r "set_trace\|breakpoint("） - 如果非要在运行时查变量，用
faulthandler.dump_traceback()+ 信号触发，比交互式调试安全得多 - 所有调试辅助逻辑必须带开关（比如环境变量
DEBUG_ATTACH=1），默认关闭，且启动时校验权限（如只允许本地 socket 或特定 IP 段）
用 logging + 结构化输出代替 print
很多人把 print 换成 logging.info() 就以为“升级”了，但没配格式、没分 level、没加 trace_id，日志一多根本串不起来请求链路。
关键不是记多少，而是能快速定位“这个错误发生在哪个请求、哪个中间件、哪个数据库连接上”。
立即学习“Python免费学习笔记（深入）”；
- 必须用
%(asctime)s %(name)s %(levelname)s %(funcName)s:%(lineno)d基础格式，时间戳要带毫秒（logging.Formatter(fmt, datefmt="%Y-%m-%d %H:%M:%S.%f")） - 每个请求进来的第一个 log 要生成唯一
trace_id，并透传到下游调用（用contextvars.ContextVar绑定，别用全局变量） - 敏感字段（如 token、手机号）要主动脱敏，别等日志系统过滤——
logging.Filter可以在 handler 层统一处理
psutil + tracemalloc 查内存泄漏比 pdb 实在
线上内存持续上涨？pdb 连对象都列不全，更别说追溯谁 new 的、谁没 del。这时候靠的是采样+对比，不是单步。
tracemalloc 开销可控（默认只记分配点，不记释放），配合 psutil.Process().memory_info() 能快速锁定增长源。
- 启动时加
tracemalloc.start(25) # 25 行堆栈深度，别用默认的 1 - 定期（比如每分钟）调用
tracemalloc.take_snapshot()并 diff 上次快照：top_stats = snapshot.compare_to(last_snapshot, 'lineno') - 注意
tracemalloc不统计 C 扩展分配的内存（如 numpy array），得配合psutil看 RSS 总量是否吻合
用 py-spy 无侵入抓 CPU 热点，不用改一行代码
服务响应变慢，又没明显错误日志？py-spy 是目前最靠谱的“隔空把脉”工具——它用 ptrace 或 procfs 读进程内存，完全不干扰 Python 解释器运行。
比 cProfile 强在：不用重启、不用改代码、能看整个进程（包括多线程/协程），且支持实时火焰图。
- 安装后直接跑：
py-spy record -p <code>PID-o profile.svg --duration 30，30 秒内所有线程的调用栈就导出成可交互 SVG - 如果进程用了
seccomp或容器禁了ptrace，换--nonblocking模式（精度略低，但能用） - 注意：
py-spy看不到纯 C 函数内部（比如 pandas 内部优化），热点落在<built-in method></built-in>上时，得结合perf top -p <code>PID看底层
真正难的从来不是“怎么装工具”，而是想清楚你要回答的问题：是某个请求慢？还是整体吞吐掉？是内存涨得不对劲？还是 GC 频率异常？工具只是帮你看清现象，归因还得靠你对业务和数据流的理解。
