不可否认，未来的一到两年中，程序员的编码体验将会发生剧烈的变化。作为一名一线开发，要如何提前准备，来应对这种变化呢？
前言
在AIGC时代，虽然深度学习模型可以仅通过一段注释来生成我们想要的代码，但是，最终要让代码跑起来的还是程序员自己，因此，调试代码，解决问题的能力相较于编码能力会变得愈发重要。
对于服务端而言，IDEA的Debugger几乎成为了调试代码的银弹。但是，笔者发现很多人在使用Debugger时，只使用了其中很小一部分功能。
在本文中，笔者将简要介绍一些自己整理的IDEA Debugger中一些鲜为人知，却能够在特定场景提升Debug效率的功能。
注意：本文不会涉及IDEA Debugger的基础操作，例如：
- 基本的Debug操作，包括但不限于：Step Over, Step Into, Step Out, Run to Cursor, Drop Frame等
- 基本的断点类型：条件断点、方法断点、线程/全局断点、字段断点、计数断点等
以上操作在各大论坛中均有优秀文章介绍。
断点
▐ 不暂停断点
尽管很多文章已经提到过断点的非挂起功能，但是由于其太好用了，所以本文也单独列出，使用方法如下。
我们在创建断点时，进入断点配置界面后：
取消勾选Suspend，并填写Evaluate and log，此时，断点将会变为黄色。
当程序运行到断点时，代码不会中断执行，而是会直接在Debugger中打印出Evaluate and log中的信息：
▐ 异常断点
- 普通断点的不足
当代码产生异常时，我们可以通过log看到异常捕获信息，然而，异常的捕获位置很可能和异常真实发生的位置相距甚远。
例如以下代码，ExceptionPoint的process方法调用了innerProcess方法，并在innerProcess方法中会产生运行时异常：
而异常捕获在上层的Filter类的main方法中：
当异常产生后，产生的log为：
可以发现，log并没有打印出异常的堆栈信息，一旦发生这种情况，尽管我们可以定位到异常是哪里被捕获的，却很难定位到异常是在哪里呗抛出的。
- 配置异常断点
为了获取异常被抛出的位置，我们可以使用IDEA中的异常断点，配置位置在断点面板的上面：
选择好需要捕获的异常类型后，需要配置断点过滤：Catch class filters
在断点过滤处，要输入捕获断点的类（本例为上层的Filter），配置完成后，重新Debug时，IDEA就会在异常将要抛出时进入断点：
在异常抛出的位置，我们就可以很容易看出方法的入参出参，从而定位问题。
▐ 依赖断点
- 断点依赖的场景
有时，目标方法可能被多个方法调用，例如以下代码，work()方法同时被warmup和realWork方法调用。
如果我们想让目标方法work()中的断点仅在被realWork()调用时才启用，要怎么办呢？
以下提供两种方法，这两种方法分别适用于不同的使用场景。
- 前置条件断点
在方法realWork()中创建非挂起断点：
在目标方法work()中如下位置增加断点依赖：仅当选中断点执行后再启用
完成上述配置后，Debug时，则仅当realWork()的断点被激活后，第二个断点才会被启用。
- 调用过滤器
另一种方法是直接创建调用过滤器，不过这种方法需要当前暂停的断点正在被目标方法调用。
使用方法为：在work()的断点行，Alt+Enter，在弹出的界面中，选择当前断点的调用条件：
选择后，IDEA会自动填充到以下位置：
同时，对于非静态方法，还可以选择Instance filters和Class filters，原理相同。
▐ 断点后悔药
如果我们好不容易按照上述方法设置了一些复杂的断点，却因为手滑点了一下，一不小心给删了，要怎么恢复呢？
以下提供三种方法，也分别适用于不同场景。
- 标准的撤回操作
在如上位置，通过点击Restore Breakpoint，即可撤销删除最近删除的断点
- 原地复活
如果我们已经进行了多个断点的删除操作，以至于上述撤回按钮已经失效了，要怎么办呢？
我们还可以在不小心删掉断点的位置再次创建一个普通断点，可以注意到，此时，IDEA会多出一个选项：
点击Restore previous breakpoint，即可恢复原来的断点。
- 一劳永逸的方法
既然我们经常一不小心删除断点，干脆修改左键为不删除断点不就好了？
IDEA也提供这一功能，位置在
IDEA默认选择第一个，我们可以将其修改为第二个，修改后，左键点击断点，则禁用断点，按鼠标中键才会删除断点，彻底避免了手滑操作。
更多精彩内容，欢迎观看：
9个服务端提升debug效率的IDEA Debugger技巧（下）：https://developer.aliyun.com/article/1263217?groupCode=taobaotech
