4、断点调试入门：设置断点、单步执行、查看变量、条件断点
调试，说白了就是让代码停下来给你看。你想想看，代码跑得飞快，你肉眼根本跟不上。断点就是那个「暂停键」，让程序在你指定的行停下来，然后你就能慢慢检查它到底在干什么。
我刚开始做游戏客户端那会儿，调试全靠打日志。满屏幕的 Debug.Log，看得眼花缭乱。后来被一个老前辈按着头学了断点调试，才发现自己之前走了多少弯路。嗯，今天就把这些经验分享给你。
4.1 设置断点：让代码停下来
设置断点很简单。在 IDE 里，点击代码行号左侧的灰色区域，就会出现一个红色圆点。这就是断点。
核心操作：
- 点击行号左侧：添加/移除断点
- 右键断点：可以设置条件或禁用
- Ctrl + Shift + F9（VS）：清除所有断点
我在项目中遇到过一种情况：断点打上了，但程序就是不命中。后来发现是代码没编译到最新版本。记住，断点必须打在可执行代码行上。打在注释、变量声明、空行上，是没用的。
小技巧：断点可以打在方法的第一行，也可以打在方法调用的地方。我个人习惯在方法入口打一个，在关键逻辑分支里再打一个。这样能快速定位问题范围。
4.2 单步执行：一步一步看代码怎么跑
断点命中后，程序就暂停了。这时候你可以控制它一步一步执行。常用的几个快捷键，你得记牢：
| 操作 | 快捷键（VS） | 快捷键（Rider） | 说明 |
|---|---|---|---|
| 逐语句 | F11 | F11 | 进入方法内部 |
| 逐过程 | F10 | F10 | 不进入方法，直接执行完 |
| 跳出 | Shift + F11 | Shift + F11 | 跳出当前方法 |
| 继续执行 | F5 | F5 | 运行到下一个断点 |
为什么要区分「逐语句」和「逐过程」？举个例子：你调试一个 Update 方法，里面调用了 MovePlayer()。如果你用 F11，就会跳进 MovePlayer 内部一行行看。如果你用 F10，MovePlayer 会直接执行完，然后停在下一行。
我曾经调试一个复杂的 AI 行为树，里面嵌套了十几层方法调用。一开始傻傻地用 F11 一层层往里钻，结果把自己绕晕了。后来学乖了：先 F10 跳过不关心的调用，到关键逻辑再用 F11 钻进去。效率高多了。
4.3 查看变量：看看数据对不对
程序停下来后，最想干的事就是看变量值对不对。IDE 提供了几种查看方式：
- 鼠标悬停：把鼠标放到变量上，会弹出当前值
- 局部变量窗口：自动显示当前作用域内的所有变量
- 监视窗口：手动添加你想跟踪的变量或表达式
- 即时窗口：可以输入表达式求值，比如
player.health + 10
重点：监视窗口里可以写表达式。比如你想看一个列表的第三个元素，直接写 myList[2]。想看看对象是不是 null，写 myObj == null。这个功能很多人不知道，其实特别实用。
我记得有一次排查一个 UI 显示 bug，角色血量明明扣了，血条却没变。我在 Update 里打了断点，用监视窗口同时看了 currentHealth 和 healthBar.value。结果发现 currentHealth 变了，但 healthBar.value 没更新。一下子就定位到是 UI 绑定出了问题。
注意：在 Release 模式下，编译器可能会优化掉一些变量。你可能会看到「无法获取值」的提示。这时候要么切到 Debug 模式，要么在代码里加一些临时变量来绕过优化。
4.4 条件断点：只在需要的时候停
有时候你不想每次都停。比如一个循环执行 1000 次，你只关心第 500 次的情况。或者一个方法被频繁调用，你只想知道当某个参数为特定值时的行为。这时候就需要条件断点。
设置方法：右键断点，选择「条件」，然后输入一个布尔表达式。比如：
// 只在 i 等于 500 时中断
i == 500
// 只在 playerName 为 "Boss" 时中断
playerName == "Boss"
// 只在血量小于 0 时中断
health < 0条件断点还有一个「命中次数」选项。你可以设置「当命中次数等于 5 时中断」，或者「当命中次数是 3 的倍数时中断」。这在调试循环或重复调用时特别好用。
我的习惯：条件断点里的表达式尽量简单。太复杂的表达式会影响性能，尤其是在高频调用的方法里。我曾经在一个每帧调用的 Update 里加了条件断点，结果游戏直接卡成幻灯片。后来改成在代码里加 if (条件) Debug.Break()，性能就好多了。
还有一个进阶用法：条件断点 + 日志输出。有些 IDE 支持在断点命中时输出日志而不中断。这相当于一个「临时日志」，不用改代码就能看到变量值。我个人觉得这个功能比打日志方便，因为用完直接删断点就行，不用清理代码里的 Debug.Log。
4.5 实战：一个典型的调试流程
说了这么多，咱们串起来走一遍。假设你要调试一个「玩家跳跃」的 bug：
- 在
Jump()方法的第一行打一个断点 - 运行游戏，触发跳跃，断点命中
- 用 F10 逐过程执行，观察
jumpForce和rigidbody.velocity的变化 - 发现
jumpForce值不对，右键断点加条件jumpForce < 5 - 重新运行，只在跳跃力度不足时中断
- 定位到是某个 buff 系统把跳跃力减半了
你看，整个过程不需要改一行代码，不需要加一个日志。这就是断点调试的魅力。
最后提醒：调试完记得清理断点。我见过有人把断点带到发布版本里，结果游戏在玩家机器上莫名其妙暂停。虽然 Unity 和 Unreal 的发布版本不会触发断点，但养成好习惯总没错。
断点调试是基本功，但很多人一直没真正用好。说白了，就是「让代码停下来，然后问它：你现在在干嘛？」。掌握了这个，你排查问题的速度至少快一倍。
下一章咱们聊聊「调用堆栈分析」，看看怎么从一堆方法调用里找到罪魁祸首。
公众号:蓝海资料掘金营，微信deep3321