启动调试与设置断点的基础流程
Python 标准库中的 pdb（Python Debugger）是一个无需额外安装的交互式调试工具，其核心价值在于允许开发者在程序运行过程中暂停执行，从而检查当前的内存状态和代码逻辑。启动调试主要有两种方式：一是在代码中插入 import pdb; pdb.set_trace()（Python 3.7+ 推荐使用内置函数 breakpoint()），程序运行至此处会自动暂停并进入 (Pdb) 交互提示符；二是通过命令行执行 python -m pdb script.py 启动调试会话。在调试会话中，可以使用 b 行号 或 b 文件名:行号 来设置断点，例如 b 15 表示在第 15 行设置断点。当程序执行到断点位置时，会自动中断并交出控制权，此时开发者可输入 c（continue）命令让程序继续运行至下一个断点或结束。这一“暂停-检查-继续”的完整流程，构成了命令行调试的基础闭环，极大提升了定位隐蔽逻辑缺陷的效率。
利用单步命令追踪代码执行路径
进入 (Pdb) 交互环境后，单步执行是追踪代码流向的核心手段。n（next）命令用于单步跳过，即执行当前行但不进入该行调用的函数内部，适合快速掠过已验证无误的底层逻辑；s（step）命令则会单步进入，若当前行包含函数调用，调试器会跳入该函数首行，便于深入排查内部实现。当确认当前断点后的逻辑无误时，输入 c（continue）可让程序全速运行至下一个断点或程序结束。若已深入某个函数且希望快速返回到调用该函数的位置，可使用 r（return）命令执行至当前函数返回。调试结束后，输入 q（quit）将直接终止程序并退出调试器。例如，在排查循环累加错误时，可先用 s 进入循环体，再用 n 逐行观察变量变化，配合 c 跳过无关迭代，从而精准锁定导致计算偏差的具体代码行。
查看与动态修改变量以验证假设
程序暂停时，准确掌握运行时状态是排查问题的关键。在 (Pdb) 提示符下，直接使用变量名或输入 p 变量名 即可打印其当前值；若数据结构较复杂（如嵌套字典或长列表），推荐使用 pp（pretty print）进行格式化输出，提升可读性。通过 locals() 命令可一次性查看当前作用域内的所有局部变量及其对应值，便于快速核对状态是否符合预期。当怀疑某个中间变量导致后续逻辑异常时，可直接在调试器中赋值修改，例如输入 count = 10 强制覆盖原值，随后使用 n 或 c 继续执行，观察程序是否恢复正常。这种“查看-假设-修改-验证”的交互方式，无需修改源码或重启程序，即可快速验证修复思路的正确性，大幅缩短调试周期。
结合异常与调用栈排查复杂问题
当程序抛出未捕获异常时，直接崩溃往往难以定位根因。此时可在命令行使用 python -m pdb script.py 启动，或在代码中配置 import pdb; pdb.post_mortem()，使程序在异常发生时自动进入调试状态。进入后，首要操作是输入 where（或 bt）查看完整的调用栈（Call Stack），该命令会按层级列出从入口函数到报错位置的所有函数调用关系。通过 u（up）和 d（down）命令，开发者可以在不同栈帧之间上下移动，检查每一层函数的局部变量与参数传递情况。例如，某底层工具函数报出 TypeError，通过 where 发现其由上层业务逻辑传入错误类型参数，此时使用 u 切换至业务层栈帧，即可直接定位到数据清洗遗漏的源头。这种自底向上追溯调用链的方法，是解决跨模块复杂异常的标准范式。
验证修复结果与常见避坑指南
调试完成后，必须通过完整运行验证修复效果，并清理调试痕迹。常见避坑包括：断点位置应避免设置在循环或高频调用函数中，否则会导致调试器频繁中断，严重影响效率；此时应使用条件断点，如 b 20, x > 100，仅在满足特定条件时暂停。此外，务必在提交代码前移除所有 pdb.set_trace() 或 breakpoint() 语句，防止生产环境意外中断。还需注意，Python 在启用优化模式（python -O）时会忽略断言与部分调试钩子，可能导致调试行为与生产环境不一致。验证阶段应移除断点，使用正常参数重新运行脚本，对比修复前后的终端输出与日志。若输出符合预期且无异常抛出，则说明定位准确、修复有效，至此完成一次完整的调试闭环。
