写代码最怕啥？不是不会写，而是改不完的 bug。尤其在手机应用开发里，用户操作路径复杂，设备机型又多，一个隐藏的问题可能要折腾好几天。这时候，断点调试就是你的救命稻草。
什么是断点调试
简单说，就是在代码某一行设个“暂停点”，程序运行到这里会停下来，你可以看看变量值、调用栈、当前执行路径，就像拍电影时喊“卡”，然后检查每个演员的位置。
在真实场景中怎么用
比如你做了一个记账 App，用户点击“添加支出”后金额没更新。你怀疑是数据没传进数据库，但日志又看不出问题。这时候打开调试器，在保存数据的那一行加个断点：
db.saveExpense(expense);运行 App，复现操作。当执行到这一行，程序暂停，你就能看到 expense 对象里的金额、分类、时间等字段是不是空的，或者类型对不对。如果发现金额是字符串 "100" 而不是数字 100，那问题就找到了。
别只会点一次断点
很多人设了断点就一直按“继续”，其实调试器提供很多控制方式：
- “单步跳过”（Step Over）：执行当前这行，进入下一行
- “单步进入”（Step Into）：如果这行调用了函数，就钻进去看里面怎么执行
- “跳出”（Step Out）：从函数内部直接跑出来，看返回结果
2024-05-20 变成 Invalid Date 的。
条件断点：只在特定情况下暂停
有时候 bug 只在特定用户或数据下出现。比如只有 iOS 17 的用户提交表单会闪退。你不可能每次都手动试一遍，这时候用条件断点。
右键断点，设置条件：
device.os === 'iOS' && device.version === '17'这样程序只在满足条件时才暂停，省下大量重复操作的时间。
查看调用栈，理清执行路径
当你停在一个断点，旁边通常有个“Call Stack”面板。它告诉你这个函数是怎么被一层层调用过来的。比如：
onSubmitForm()
→ validateInput()
→ checkEmailFormat()
→ [当前断点]一眼就知道是从哪个入口触发的，方便你回溯逻辑。
手机真机调试也不难
很多人觉得断点只能在模拟器用，其实连真机也能调试。Android 开启 USB 调试，iOS 用 Safari Web Inspector，连上电脑后，在 Chrome DevTools 或 VS Code 里照样能设断点。
有次我同事的 App 在华为手机上总卡住，模拟器却没问题。连上真机一调试，发现是某个动画库在低内存机型上超时。断点停在定时器那里，内存占用一看就爆了。
别忘了观察表达式
除了自动显示的变量，你还可以手动添加“Watch Expression”。比如你想盯住 user.isAuthenticated，不管它在哪变的，只要值一改，你就知道。
这在处理异步登录状态时特别有用。用户点了登出，但页面没刷新，看看这个值到底变没变，还是中间被别的逻辑覆盖了。
断点调试不是高级技巧，而是每天都在用的基本功。用熟了，修 bug 的速度能快好几倍。下次遇到问题，先别急着删代码重写，打个断点，让程序自己告诉你答案。