在 Ubuntu 下跑 Python 出错时，很多问题并不需要复杂工具，先把异常信息、执行位置和变量状态看清楚，往往就能很快定位。下面按“先快筛、再深入”的顺序整理一套常用调试方法，方便你判断什么时候看终端、什么时候加 print、什么时候该切到 pdb 或 IDE。

先把错误信息读完整

调试的第一步不是立刻改代码，而是把终端里出现的异常提示完整看一遍。异常类型、报错位置和调用栈，通常已经给出了很直接的线索。很多人在看到报错后只盯着最后一行，其实前面的调用路径同样重要，它能告诉你问题是在哪一层函数里传下来的。

如果是语法错误、名称错误、类型错误这类常见问题，错误信息本身往往已经足够定位；这时先确认触发异常的代码行，再回头看这一行依赖的变量和上游逻辑，通常比盲改更有效。

先用 print 快速缩小范围

当报错信息还不足以直接看出原因时，最省事的办法通常还是加 print。它适合用来确认程序到底有没有走到某个分支、关键变量在运行时拿到了什么值，以及函数之间传递的数据是否符合预期。

这种方法虽然朴素，但在排查逻辑错误时非常高效。尤其是在脚本不大、问题范围已经大致明确的情况下，直接在关键节点输出变量，往往比先搭复杂调试环境更快。这里的重点不是到处乱打日志，而是围绕“输入是什么、分支怎么走、输出变成了什么”来放置少量关键信息。

print 不够时，再切到 pdb

如果仅靠输出信息仍然看不清执行过程，就可以使用 Python 自带的 pdb。在目标位置插入下面这行代码：

import pdb; pdb.set_trace()

程序运行到这里会进入交互式调试状态，你可以边执行边查看上下文。对大多数 Ubuntu 下的 Python 脚本来说，这一步已经足够覆盖绝大多数深入排查需求。

常用命令可以直接记住这几项：

n  # 执行下一行
s  # 进入函数内部
c  # 继续运行到下一个断点
q  # 退出调试
p  # 打印变量值
l  # 查看当前代码上下文
w  # 显示调用堆栈

它们的使用思路很简单：先用 l 和 w 看清当前代码位置与调用关系，再用 p 检查变量值，接着用 n 或 s 逐步推进。这样比反复运行脚本、靠猜测改代码更稳，也更容易抓到状态变化发生的具体位置。

需要效率时用 IDE，卡住了再查文档和社区

如果你平时就在 PyCharm、VS Code 这类编辑器里开发，图形化调试器通常会更顺手。设置断点、单步执行、实时查看变量值，都能在界面里直接完成，尤其适合函数调用较深、变量较多的场景。和命令行调试相比，它的优势主要在于信息更集中，来回切换上下文的成本更低。

当本地已经排查一轮，问题还是没有结论，就该去查官方文档或 Stack Overflow 这类社区。此时不要只贴一句“代码报错了”，而要尽量提供完整的错误信息、最小可复现代码，以及你已经尝试过的步骤。这样别人才能快速判断问题是环境、语法、依赖，还是业务逻辑本身导致的。

如果把这套顺序固定下来，Ubuntu 下的 Python 调试通常会清晰很多：先读报错，再用 print 缩小范围，接着用 pdb 或 IDE 深入查看，最后再借助外部资料补充判断。多数问题并不难，难的是没有按层次排查。