写代码时，最头疼的莫过于捉摸不定的 Bug。它像躲进代码深处的精灵，让人抓狂。
今天我们来聊聊 Python 的 debugpy 模块，一个能把调试过程变得像看侦探剧一样清晰的神器。
🎯 为什么是 debugpy？先让它跑起来
它的强大在于，不仅能调试本地脚本，还能像章鱼一样，将触手伸到远程服务器、Docker 容器里。我们先把它请出来，让它“监听”我们的代码。
# 1. 首先，安装并导入它（通常无需安装，VS Code自带）
import debugpy
# 2. 告诉它我们要监听哪个端口，等待调试客户端连接
# 5678 是默认端口，就像给门留了个特定的猫眼
debugpy.listen(5678)
print("调试器已就绪，正在等待客户端连接...")
# 3. 程序会在这里暂停，直到我们的调试器（比如VS Code）连上来
debugpy.wait_for_client()
print("调试客户端已连接，开始表演！")
执行上面这段代码，终端会停在 wait_for_client，静静等你。
当 VS Code 配置好远程调试并连上 5678 端口后，才会打印出“调试客户端已连接”。
🚀 实战：打断点就像“定身术”
等待连接后，真正的魔法开始了。我们可以在代码里随心所欲地设置断点。
程序执行到断点处，就像孙悟空喊了声“定”，一切状态都被冻结，任你查看。
# 假设我们有个有点复杂的函数
defcalculate_bonus(sales, rate):
print("计算奖金函数被调用了")
# 这是一个断点，程序执行到这里会暂停
debugpy.breakpoint()
bonus = sales * rate
print(f"计算出的奖金是：{bonus}")
return bonus
# 调用函数
sales_amount = 15000
bonus_rate = 0.12
final_bonus = calculate_bonus(sales_amount, bonus_rate)
print(f"最终应发奖金：{final_bonus}")
当调试客户端连接后，执行此脚本。
程序一碰到 debugpy.breakpoint() 就会立刻暂停，此时 sales 和 rate 的值都冻结在当前状态，方便我们检查逻辑是否正确。
🔍 灵魂三问：我是谁？我在哪？我要干什么？
暂停后，我们就可以在调试器里执行“灵魂三问”，查看当前作用域里的所有变量。
这比满世界写 print 函数高效得多，而且干净利落。
# 继续上面的场景，我们可以在暂停后，通过调试控制台执行命令
# 假设我们想偷偷修改一下逻辑，看看结果会怎样
current_sales = 15000# 这是当前变量
# 调试器里我们可以执行：
# print(f"当前销售额: {current_sales}")
# 甚至可以当场修改变量：
# current_sales = 20000
print(f"调试时被我修改后的销售额变成了: {current_sales}")
当然，这段代码本身不会自动修改变量，它的价值在于展示：当程序在断点处冻结时，我们能通过外部调试器（如 VS Code 的调试控制台）自由地探索和修改变量，这是 print 调试无法比拟的。
🆚 debugpy vs. 其他调试工具
说到调试，Python 自带的 pdb 是轻量级选手，功能纯粹但交互体验一般。而 ipdb 继承了 IPython 的衣钵，补全和展示更友好，但主要还是面向本地终端。
建议：日常本地开发，用好 VS Code 就是用好 debugpy。遇到棘手的线上问题或 Docker 环境，debugpy 是你应该最先想到的瑞士军刀。
📝 写在最后
debugpy 把调试从“猜谜游戏”变成了“解谜游戏”。
它让我们有机会真正走进代码的运行世界，而不是靠猜测和 print 来推断。希望今天这个小工具，能帮你下次面对 Bug 时，多一份从容，少一丝烦躁。
你在远程调试或本地调试时，遇到过什么“灵异事件”吗？
或者你有自己独特的调试技巧？欢迎在评论区留言分享，我们一起交流探讨～
