不想跟那帮“克隆仓库、跑个 Hello World 就收工”的教程作者一样，我先把话放在前面：IntelliJ IDEA 能在 Spring 应用调试这件事上被叫一声“神器”，靠的不是它默认给你塞的那一堆按钮，而是它把断点、上下文、对象状态和 Spring 容器内部信息串联起来的能力。你用记事本也能写好 Spring 代码，但遇到真正恶心的 Bug，比如 Bean 还没初始化完就被拿去用、循环依赖绕来绕去、配置项明明写了却就是没生效，靠“加日志、看输出、猜原因”这套流程，半天都未必能定位到问题。IDEA 的调试器可以把整个调用链路拉到你眼前，每一步变量怎么变的、哪个对象是空的、哪个代理类被拦截了什么链路，全部看得清清楚楚。
我见过很多开发者，IDEA 用了好几年，调试面板只认识 Resume、Stop 和 Step Over，断点只会打行号，从来没用过条件断点和异常断点。到了 Spring 项目里，启动上下文贼长，请求链路还层层嵌套，这种用法自然体验不到“神器”的滋味。这篇东西就是要把它掰开揉碎地讲清楚：哪些场景值得开断点、Spring 专属的调试手法怎么操作、以及那些你八成会踩的坑和对应的排查思路。不管你是刚接触 Spring Boot 的新人，还是被线上问题折磨到秃头的老手，照着里头的流程走一遍，调试效率起码翻一倍。
1. 为什么是“Spring调试神器”：IDEA与Spring调试的真实痛点
1.1 传统调试方式让人抓狂的地方
一年前有个同事让我帮忙看一个诡异问题，他说：“服务能启动，请求也能打进来，但只要一调用某个 Service 就报空指针，我看了半天代码，逻辑一点毛病没有。” 我让他把 System.out.println 全删了，开个调试器，先在 Controller 入口打个断点，然后 Step Into 进去看每一步的变量值。十分钟不到就找到了：注入的 Service 被另一个切面类包了一层，切面里面拿了一个初始化失败的属性，结果整个代理对象变成半成品，外面代码看起来“非空”，进去调用时真正的方法已经坏了。
这个例子能说明传统调试方式的三个核心痛点：
- 靠日志猜状态：日志只能记录你提前想好要输出的内容，可在复杂调用链里，你根本不知道哪一步会产生问题，于是只能一轮接一轮地加日志、重启、复现，循环往复。
- 看不到对象内部结构：System.out.println 只会调用 toString()。很多框架对象、代理对象、Spring 包装对象的 toString() 要么写得特别敷衍，要么干脆抛异常，你根本看不到真实状态。
- 断点只会单步执行：新手习惯一行一行“Step Over”，可 Spring 的方法调用层级动辄几十层，CGLIB 代理、JDK 动态代理、事务拦截器穿插其中，一单步就跑进莫名其妙的底层代码，最后迷路。
所以我说，IDEA 调试器的真正价值，不在于“能打断点”，而在于它把“运行到某一行时的整个内存现场”完整开放给你看。Spring 容器又是重框架，本身有大量运行时生成对象和代理对象，只有这种级别的可见性，才能让你把问题从“现象”倒推到“根源”。
1.2 IDEA 让 Spring 调试少踩坑的核心能力
用 IDEA 调试过 Spring 项目的人都会有感觉，几个能力是最值钱的：
第一，对 Spring 运行时的感知。IDEA 能识别 Spring 的 Bean、配置类、自动配置类，启动阶段就在后台建立了索引。调试时你点开变量树的某个对象，IDEA 可以直接显示这个 Bean 的类型、作用域、代理状态，甚至能看到处理后置增强器给它附加了哪些特性。有人说它就是一个“能摸到容器内脏的手术钳”，这话不夸张。
第二，表达式求值功能足够猛。在断点停住时，你可以打开 Evaluate 表达式求值窗口，执行当前上下文里任何可以执行的代码。比如你怀疑某个 Service 注入的 Repository 是不是同一个实例，直接在表达式窗口里输入applicationContext.getBean(UserRepository.class)跟当前变量比较一下地址，立刻见分晓。这种行为在普通日志方案里基本做不到。
第三，条件断点和异常断点让“大海捞针”变成“定向捕捞”。Spring 项目里，一个 Bean 可能会被实例化很多次，一个通用方法会被频繁调用，如果你只想在特定状态或者特定参数时停下来，条件断点能直接过滤。异常断点就更有用了，不管哪里抛了 NullPointerException，调试器都能第一时间给你断在抛异常的那一行，根本不用去猜“到底哪里出的错”。
这些能力单看都只是几个菜单项，组合起来就是一套完整的“运行时诊断工作流”，对 Spring 这种框架级项目特别合适。
1.3 这篇博文适合谁
这篇内容适合三类人：
- 刚学 Spring Boot 不久的入门者：你会发现原来调试器可以省掉那么多烧香拜佛式的猜测，写完一个简单功能到出 Bug 的定位路径会清晰很多。
- 工作经验一两年、却还没系统性掌握 IDEA 调试面板的开发者：把断点类型、表达式求值、线程上下文这些东西补齐后，排查 Starter 包冲突、Bean 装配异常这些典型问题，会快得多。
- 被各种“无法复现的偶发问题”折磨的维护者：通过条件断点和异常断点，你可以把调试器变成一个只关心特定条件的哨兵，挂在那等它触发就行，不需要一遍遍手动复现。
对于已经非常熟练的老手，这篇可能更像一次系统梳理，也许还能翻出几个你平时没用顺手的角落功能。
2. 断点系统拆解：每种断点用在哪、怎么用
如果你只知道在行号旁边点一下小红点，那等于抱着金饭碗要饭。IDEA 的断点体系至少包含行断点、条件断点、方法断点、字段断点、异常断点这几类。在自己项目里按需组合，才能应对 Spring 里千奇百怪的故障现场。
2.1 行断点与条件断点：最常用组合技
行断点就是最基础、最常用的断点类型。点一下行号右侧，程序执行到这一行就停下来。但它有两个容易踩的细节：
- 断点只会在“当前线程执行到这一行”时生效。Spring 多线程处理请求时，多个线程都在跑同一个方法，你打算观察哪个线程，就需要配合“挂起策略”来设置。
- 如果某行被频繁调用（比如批量处理几万条数据），你按一次 Resume，它又立刻停下来，这样根本没法往后看。这时就该用条件断点。
条件断点的操作方式很直接：右键断点，在弹窗里写一个布尔表达式。比如你在一个 for-each 循环里处理用户订单，想只看某个特定用户：
order.getUserId().equals(9527L)代码执行到这一行时会先计算这个条件，结果为 true 才暂停，为 false 就直接跳过。条件里也能调方法，比如list.size() > 100，但要注意，频繁调用的方法被断点条件反复执行，本身会影响性能，所以条件里尽量用简单字段判断。
在 Spring 项目里，条件断点最常见的用法是拦截特定请求。一个 Controller 方法给多个参数组合提供服务，你想只在type = 3时调试，条件就可以直接写成type == 3。更复杂的，你可以看某个 Bean 的某个属性满足什么状态才停下。这种定向捕捞能大幅减少无效打断点的时间。
还有两个小按钮很多人没用过：在断点属性窗口里，有一个“Log evaluated expression”选项，勾选后断点命中时会往控制台输出表达式结果，不会中断程序。这就相当于动态加日志，并且在真机远程调试时也可以使用。一些线上问题不好直接暂停服务，我会在关键节点加这种“日志断点”，让程序继续跑，只是顺路把信息打印出来。
2.2 方法断点、字段断点、异常断点：定位隐蔽 Bug
方法断点在方法声明那一行打，方法进出的时候都会暂停，能直接看到入参和返回值。有人觉得它速度慢，确实，IDEA 自己也会给方法断点加 JIT 禁用之类的提示。但在 Spring 里，查找一个接口实现类的入口路径非常方便，比如你只知道某个 Service 接口被调用，但不知道具体是哪个实现类，方法断点直接断下来告诉你。
字段断点是我在调试 Spring 容器问题时的秘密武器。在字段声明行左侧打点，选上 Field 断点，这个字段每次被读写都会停下。Spring 很多 Bug 出在“某个 Bean 在初始化后被别的代码悄悄改掉了状态”，靠肉眼扫代码很难照出来。字段断点可以让你纵观这个字段的整个生命周期，谁初始化了它、谁又把它改成了 null。比如我发现某个全局配置对象内容不对，在这字段上打上断点，观察所有写入点，基本上一次就能把篡改位置揪出来。
异常断点是排查空指针、数组越界这类问题的终极法宝。它不会绑定任何具体代码行，而是监听某类异常。Add Exception Breakpoint，输入NullPointerException，之后你运行程序，只要能执行到抛异常的位置，调试器立刻给你停下来。注意，断的位置是“抛异常的那一行”，而不是“catch 住的那一行”，这非常关键。Spring 的 AOP、事务代理层经常把底层异常包一层新的异常抛出来，如果没有异常断点，你只能在外层捕捉到异常后靠堆栈往回猜，有了异常断点，一步直达原始现场。
用异常断点时建议勾上“过滤某些包”，否则第三方框架内部也会抛出大量“已经被捕获处理”的异常，把你打断烦。IDEA 里的异常断点默认也支持“会捕获到的异常是否暂停”这种选项，细节层次够深，自己按场景调整就好。
2.3 断点命中后的查看姿势：Variables、Watches、Evaluate
断点命中只是第一步，真正提取信息靠后面这几个面板：
- Variables 面板：显示当前上下文中所有局部变量、静态变量、以及 this 对象。Spring 调试时，我通常会展开
this来确认当前对象是否被代理。怎么判断？看类名末尾是否出现了$$、CGLIB、$Proxy之类的字样。比如com.example.service.UserServiceImpl$$EnhancerBySpringCGLIB$$abcdef就说明你正在看的是一个代理对象。如果当前逻辑在事务方法里，看到代理对象是正常的，但若你在普通方法里也看到代理，也该想想是不是切面加得太随意了。 - Watches 面板：添加一些你需要持续观察的表达式。比如
userService.getStatus()或request.getParameter("id")。每次单步执行时，Watches 里的表达式都会自动重新计算。比在 Variables 里一层层展开快得多。 - Evaluate Expression 表达式求值：快捷键是 Alt + F8，弹出一个输入框，可以执行任意上下文可用代码。前面说过的
context.getBean(...)、new JSONObject(entity)都可以在这里执行。更骚的是，你还能执行一个 setter，在运行时直接改动某个变量值再继续跑。比如你把一个本该为 null 的对象临时塞进了某个字段，然后继续执行，观察后续逻辑是否因此正确运行。这在验证“是否是某个字段为空导致问题”时特别高效。
有了这三个面板，你就不再是“看代码猜”，而是直接在运行时验证猜想。插一句，Spring 项目里变量树会特别深，Bean 里面套着依赖，依赖里又套别的 Bean。这时候不必一个个点开，直接在 Watches 里写表达式获取深层属性，比手工展开省事一个量级。
2.4 Spring 调试里的断点配置技巧
逐个讲完断点类型之后，再分享几个具体到 Spring 场景的配置技巧。
第一，调试 Spring 启动过程要小心挂起策略和动态类加载。在启动阶段打断点，比如在ApplicationContext刷新方法里打断点，你会看到很多“内部类加载器”触发的后台线程也在执行框架逻辑。默认的断点策略是All，也就是任何线程命中都会停。Spring 启动会启动很多生命周期回调线程，打一个断点能被中断好多次，极其烦躁。右键断点，把挂起改为Thread，再配合条件，或者干脆只在你关注的线程上停下。
第二，Spring 的 Bean 创建过程经常是堆栈深、被代理多遍。看调用栈（Frames 面板）时，不要只看最上面几层，往下翻，能看到 Bean 实例化链条：AbstractAutowireCapableBeanFactory.doCreateBean→applyBeanPostProcessorsBeforeInitialization→ 我们的初始化方法。很多“为什么我的 @PostConstruct 没执行”一类问题，只要在这一串栈里点几下就能看出是哪一步被跳过了或者抛了异常。
第三，远程调试时的断点计算开销。本地调试随便打断点没问题，远程调试则要考虑每一条断点条件都需要通过调试协议下发到远端计算，频繁命中的条件断点可能拖慢线上应用。远程场景里我更常用“日志断点”，或者只上异常断点，这样对生产进程影响最小。
3. Spring Boot 项目调试全流程实操
光讲功能不讲连贯流程，还是没法落到项目里。下面我用一个比较典型的 Spring Boot 项目为例，把从启动配置到定位问题的完整过程走一遍。
3.1 从启动配置到首断点
先做最基本的运行配置。IDEA 里内置了对 Spring Boot 的启动支持，你只要打开主类，直接点类名旁的 Run 图标，就能启动。但正式调试时我会专门建一个 Configuration：
- 在运行配置中选择 Spring Boot 启动项类型。
- 设置好主类和 VM 参数，比如项目需要特定 profile 时加上：
-Dspring.profiles.active=dev。 - 工作目录一般不乱动，但涉及文件读取功能时，要确认这里指向的是模块根目录，否则会用相对路径读到片面的位置。
然后点击“Debug”小虫子按钮启动。启动后第一次遇到断点时，程序会停下来。此时如果 Frames 面板里出现的是ThreadPoolTaskExecutor、NettyRuntime之类的线程堆栈，而你并没有在那里打条件断点，很可能就是前面说的挂起策略的问题。建议通过左下角线程列表选择当前请求所在的线程，再在 Frames 里定位到自己代码的栈帧。
正常调试请求时，我喜欢先在 Controller 方法的入口打一个断点，确认请求已经到达后端。这一步可以排除很多前置疑问：URL 映射是否生效？拦截器是否拦截？参数解析是否正确？如果 Controller 断点都不进，那问题多半在前面，要么请求根本没到，要么被拦截器抢先拦住了。
然后逐层往下 Step Into。Spring 的调用链有大量代理和拦截器，新手总会抱怨“一进去就跳到 CGLIB 里”。我一般这么处理：先看当前对象是不是代理类，如果是，就直接使用“Step Out”跳回上层，然后从 Frames 里选择合适的栈帧来观察真实业务方法。这个技巧能帮你绕开无数框架噪音层。
3.2 热更新与DevTools：改完代码不用重启
Spring 项目重启一次的成本不低，上下文初始化、数据库连接、依赖装配动不动十秒起步。一边调试一边改代码，每次都重启，节奏很容易拖垮。IDEA 在这块提供了两个层面的热更新机制：
第一种是热重载 Java 类和资源。IDEA 在调试模式下，修改方法体内部代码后，它会尝试用 JVM 的热替换能力，把新的字节码替换进正在运行的 JVM。快捷键是Ctrl+F9（重新编译），改完再回到正在调试的窗口，继续执行时新代码可能已经生效。但要注意，这只适用于“方法体内部”的修改。如果你改了方法签名、加了字段、改了类继承结构，热替换失败，IDEA 会提示你重启才能生效。
第二种是Spring Boot DevTools。这个库在 classpath 里时，IDEA 检测到类变化，会触发应用上下文自动重启（不是 JVM 冷启动，而是 Spring 上下文重新加载，快不少）。配合调试模式，手动补一个依赖即可：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency>加了 DevTools 后，改完代码，IDEA 会自动触发重启，你再重新打请求，就能看到在新代码上跑的调试效果。也有很多团队出于对构建环境一致性的担忧，要求生产环境排除掉 DevTools，idea 上本地调试使用还是舒服的。这取决于团队规范，但至少开发环境可以保留。
热更新虽好，也有它的坑。有一次我改了一个方法的入参名，没有改变签名，IDEA 在 Debug 模式下提示热替换成功。但实际跑起来，旧的对象实例还挂在 Spring 容器里，新方法没有真正生效。排查了半个小时，最后确认是热替换的边界问题。经验是：只要涉及状态、字段、初始化逻辑，别信热替换，直接重启。省下的时间远没有踩坑花掉的时间多。
3.3 远程调试 Java 进程
本地能重现的问题，怎么都能调。真正头疼的是，问题只出现在测试环境或者已部署的服务器上，本地数据造不出来。这时候远程调试就登场了。Spring Boot 应用启动时加上远程调试参数：
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar app.jar然后在本机 IDEA 里创建一个 Remote JVM Debug 配置，填上服务器的 IP 和端口 5005，点击 Debug 就能挂上去。挂上以后，本地打断点、看变量、执行表达式，和调试本地进程几乎一样。
远程调试有几个实用经验：
生产环境安全要求高，别随随便便开调试端口。
调试连接通道是明文的 JDWP 协议，端口暴露有一定风险，通常只用于临时排障，用完立刻关掉。
远程调试会显著影响应用性能，尤其是断点命中的瞬间会把线程挂起，所以不要在核心请求链路上冒烟乱打。我会用前面提到的日志断点，先打桩观察变量，再决定是否真的停下线程。
如果远程应用跑的不是你本地这份代码，查起来会非常误判。开启远程调试前，先确认远端代码 SHA 或者构建时间和你本地一致。
我曾经调试测试环境的一个缓存问题，远程断点命中了又死活看不到关键变量，最后才发现测试环境的 Jar 包是前一天构建的，跟本地源码差了俩提交。对齐代码版本这个步骤，讲多少遍都不为过。
3.4 实战场景：启动失败的调试过程
用一个具体场景串一遍。假设你启动 Spring Boot 时报错：
Parameter 0 of method setUserRepository in com.example.service.UserServiceImpl required a bean of type 'com.example.repository.UserRepository' that could not be found.启动报错信息已经足够明显，是缺少 UserRepository 这个 Bean。但真正的难点在于：为什么这个类没有被 Spring 扫描到？我调试时的流程是：
- 在项目里搜索
UserRepository所在包，确认它的包路径在 Spring Boot 主类的@SpringBootApplication扫描范围内。不在范围内的话，Bean 当然找不到。这个用肉眼和搜索就能解决。 - 如果在扫描范围内，直接在
UserRepository接口或实现类的类声明处打一个方法断点（类加载时的clinit或构造方法断点）。 - Debug 方式重启应用，观察这个类是否真的有被 Spring 触碰。命中不到断点，说明容器压根没扫描到它。命中到了，再看是在什么阶段被初始化。
这个场景对新手特友好，因为“找不到 Bean” 一半是包路径问题，一半是创建前置步骤失败。方法断点能让你直接确认“容器到底有没有尝试创建这个类”。一旦确认容器尝试创建了，再断到具体的构造方法、@PostConstruct方法里，一层层看哪个属性注入失败，基本就能定位了。
启动失败还有另一类是循环依赖。Spring Boot 高版本默认不允许循环依赖了，启动直接抛BeanCurrentlyInCreationException。用调试器看这种问题，重点在于找到那个“转圈”的依赖链。断点打在DefaultSingletonBeanRegistry.getSingleton方法上，配合表达式查看当前正在创建的 Bean 名集合，能很清晰地看到 A 等 B、B 等 A 的链条。虽然也可以靠堆栈文字硬读，但直接看创建的 Bean 名集合更直观。
4. 高频Spring问题场景：排查经验与避坑清单
举几个我在实际项目里高频遇到的 Spring 调试场景，以及搭配 IDEA 调试器的具体排查套路。说“避坑清单”不是夸张，这些坑我基本都踩过一遍。
4.1 Bean创建失败与循环依赖
刚才说了启动失败的找法，这里再补充循环依赖详细的调试技巧。Spring 解决循环依赖的核心存储是“三级缓存”，如果你理解这三个缓存，排查循环依赖会特别轻松。
- 一级缓存：完整创建好的单例 Bean 集合。
- 二级缓存：提前暴露的早期 Bean（半成品）。
- 三级缓存：存放创建 Bean 的 ObjectFactory。
当报错出现时，直接在DefaultSingletonBeanRegistry的相关方法里打断点，查看singletonObjects、earlySingletonObjects、singletonFactories这三个集合。你会发现 A 在三级缓存里，B 在创建中又要回头拿 A，而 A 的完整实例还不在第一级里，所以抱错。这时你就能从代码层面理解，到底是哪里形成了无法打破的环。
短期的解决办法是加@Lazy切断依赖，长期的建议是从设计上重构依赖关系，别老指望着框架开绿灯。IDEA 调试器让你能看到这些集合的内部，等于把 Spring 容器最神秘的部位直接剖开给你看。
4.2 配置属性不生效的问题
Spring Boot 项目里配置属性不生效的典型场景是：application.yml里写了值，@ConfigurationProperties类里也有字段，但运行时读出来就是默认值或者 null。
遇到这类问题，我会直接在配置类的 setter 方法里打断点，比如：
public void setMaxPoolSize(Integer maxPoolSize) { this.maxPoolSize = maxPoolSize; // 断点在这里 }如果 setter 根本不被调用，说明 Spring 没有把配置文件绑定到这个对象上，要么是@ConfigurationProperties没有被扫描，要么是配置前缀不匹配。如果 setter 被调用了，你展开this，看看绑定进去的值是什么。有可能 YAML 里写了max-pool-size，但字段叫maxPoolSize，relaxed binding 也没成功，你看到的值就是 null。这时你再去看配置里的命名和字段命名差在哪，问题立刻浮现。
还有一种情况是配置类被其他代码 new 出来了，而不是被 Spring 管理。在构造方法打断点能确认实例化的调用栈，如果创建者不是你预期里的 Spring 容器，那你等于造了一份无人认领的配置副本，业务代码引用到的自然是另一套。
还有被忽略的：配置属性明明改了但服务没重启。Spring Boot 有些属性是启动时一次性读取的，改动后不重启不代表你代码有问题，而是运行时根本不会重新加载。用调试器挂上去看变量，一眼就能确认当前进程里加载的是旧值。
4.3 线程切换、异步调用与上下文丢失
Spring 里@Async、ThreadPoolTaskExecutor、异步消息监听经常引入一类难题：调试断点进得去，但拿不到请求上下文。比如你在异步方法里想获取 RequestAttributes，发现是 null。
调试时能不能直接看到问题在哪个环节丢的？可以。在异步入口方法上打断点，先看当前线程的RequestContextHolder里有没有值。然后在提交线程池任务的位置打断点，看任务封装时有没有把上下文传递进去。最后在异步方法开端点看另一条线程，确认上下文是否真的丢失。三步下来，问题出在“入口没设置”“提交时没传递”“线程池装饰器没生效”这三者中的哪一个，清清楚楚。
IDEA 的线程视图在这种场景里特别实用。断点命中后，左下角会列出当前所有线程，你可以直接切到另一个线程观察调用栈。比如你发现任务丢到线程池后，执行线程是SimpleAsyncTaskExecutor而不是预期的某个自定义线程池，那就要回到配置里检查线程池定义有没有被真正使用。这种“线程级”的排查，日志方案根本做不到同等效果。
4.4 缓存、懒加载和数据源问题
最后一个大坑是我最常被问到的：缓存。
Spring 的@Cacheable注解看着简单，实际调试起来很考验经验。它是通过 AOP 代理实现的，你如果只在方法内部打断点，可能发现“方法没执行”但返回值又是对的——那就是命中了缓存。此时应该在方法的调用入口打断点，观察被代理对象是不是已经注入了CacheInterceptor。或者更直接地，在打断点里看方法上的 Spring 缓存 key 计算过程，判断 key 是否跟你预期一致。如果 key 多带了几个参数，缓存会命中一堆看似不合理的数据，这类问题做成条件断点挂在 key 计算的好处里，排查效率极高。
懒加载@Lazy也容易埋雷。某些 Bean 只有真被调用时才初始化，如果初始化逻辑里依赖了启动期才能获取的配置或者资源，等它真正执行时会突然爆出奇怪的异常，而且抛异常的地方离根因很远。调试时，断在第一次调用这个懒加载 Bean 的代码处，用表达式求值执行一次目标 Bean 的获取方法，观察初始化链路上哪个环节异常，比你在业务层里翻找半天强得多。
数据源问题一般是这样的：连接池在启动时不会把连接全建好，等到第一次请求，HikariCP才会真正拉连接。报错往往在业务方法里出现“Connection is not available, request timed out”。调试时先不要直冲业务代码。打开表达式求值，执行：
((HikariDataSource) dataSource).getHikariPoolMXBean().getActiveConnections()看看当前池子里到底多少连接，多少在等待。如果池被耗尽，再查是不是哪里并发把连接拿住没还。IDEA 的表达式求值配合数据源内部状态方法，能让你直接看到池的实时数据，而不是靠猜。
5. 一些调试习惯与快捷键，顺手但不平凡
再分享几个关于调试效率的细节。没什么高深技术含量，但能减少很多疲劳操作。
我在 Spring 项目里调试时最常用的快捷键：
F8：Step Over。普通单步执行，但遇到代理方法会容易进去。谨慎用。F7：Step Into。真正想深入方法内部时用。进到 CGLIB 或者 JDK 代理里面，觉得没必要就Shift + F8退出来。Alt + F8：Evaluate Expression。这个是最高频的武器，几乎每次断点都要用。Ctrl + Shift + F8：查看和管理所有断点，快速临时禁用一批。
临时禁用断点这个功能，在调试“断点冲突”时特别救命。比如你启动时有个断点在 Spring 生命周期回调里，每次启动都要停一次，烦得要命。你可以不删它，只把它临时禁用，等进入业务阶段再启用。管理断点窗口里还能对所有断点批量生效、失效或删除。
另外，IDEA 的Frames 面板右上角有一个“Drop Frame”的功能，可以让你从当前栈帧“回退”到上一个方法。有人以为它能撤销程序修改，其实它只是重新弹出一个旧栈帧，变量状态不会真的回滚。但在 Spring 调试里，如果你深入了好多层框架代码，不想继续走了，可以 Drop Frame 退回到自己的业务方法重新看流程，非常顺手。
我个人还有个“坏习惯”：喜欢在公共工具方法里用日志断点而不是直接写日志代码。因为日志断点可以随便加、随便删，不污染代码。线上排查时尤其如此，工程上不想动代码的场合就用onError或者Log message断点形式。如果你也讨厌为了调试反复改代码，这招值得一试。
最后说说快捷键的意义。Spring 项目代码量通常不小，调用层数多，每次鼠标点界面切换面板的时间积累起来是非常可观的。把基础调试键融入肌肉记忆，注意力才能集中在变量状态和调用栈上，而不是浪费在界面上。
6. 用 Debug 思维去读 Spring，而不是背结论
文章写到这，我想回头说点感想。很多人网上搜 Spring 问题，搜到“循环依赖报错怎么解决”“Bean 找不到怎么解决”，拿到一个结论就跑了。下次换个包装，同样的底层问题又不会了。老老实实用 IDEA 调试器把 Spring 容器运行时的状态看一遍之后，你会发现那些结论本质上都是“容器在这种状态下做出的必然反应”，根本不需要背。
我自己的体会是，IDEA 对 Spring 的调试价值，是所有功能加在一起形成的整体效应：条件断点让你高效定位到确切起点，异常断点帮你抓住任何隐蔽的错误爆炸点，表达式求值与 Watches 让你在运行时任意验证猜想，线程面板让你看清 Spring 多线程架构下问题到底从哪条线冒出来。这些环节少一个，体验都会打折扣，凑齐了，调试器就不再是“看代码”的工具，而是一把真正能捅进运行时内部的手术刀。
调试技能这种东西，光看不练永远不是自己的。找一个你常见到的 Bug 场景，比如启动失败、缓存命中异常、配置项没生效，用这篇里介绍的方法完整走一遍，看一遍变量变化，再对比你以前“加日志猜问题”的做法，我相信你会立刻感觉到差距。我就是这样，从无数次把时间浪费在重启和 println 里的日子，慢慢变成现在这样，遇到问题先想“我在哪个环节打断点能看到真现场”，心里就有底了。
