断点加在内部类无反应，首要确认target/classes下是否存在Outer$Inner.class等对应字节码文件，并确保其LineNumberTable属性完整；其次检查launch.json中mainClass是否指向外层类、projectName是否正确定义模块，且Lombok等注解处理器已正确配置并执行generate-sources阶段。
断点加在内部类里却没反应，先看 class 文件有没有生成
内部类（包括成员内部类、匿名内部类、局部内部类）的 .class 文件名不是 Outer$Inner.class 就算完事——VSCode 调试器必须能在 target/classes（或 Gradle 的 build/classes）下找到它，且其字节码里得有正确的 LineNumberTable 属性。常见陷阱是：Maven/Gradle 没触发注解处理器（比如 Lombok 的 @Data 生成的 getter/setter 在内部类里），或用了 mvn compile 但漏了 generate-sources 阶段。
- 运行
mvn compile后，手动检查target/classes/com/example/Outer$Inner.class是否存在 - 如果用 Lombok，确认
pom.xml中lombok依赖 scope 是provided，且启用了 annotationProcessor（IntelliJ 默认开，VSCode 需额外配置maven.compiler.annotationProcessorPath） - 局部内部类（定义在方法里的）容易被编译器优化掉，尤其当方法体为空或仅含常量时，JVM 可能根本不加载该类 —— 加个
System.out.println("debug")强制保留
launch.json 里 mainClass 写的是外层类，但调试器找不到内部类源码
VSCode Java 调试器靠 mainClass 字段定位启动入口，但它不会自动推导内部类路径。如果你在 Outer$Inner.class 里设断点，而 launch.json 的 mainClass 是 com.example.Outer，调试器可能压根不加载 Outer$Inner 的符号信息，导致断点灰化。
- 不要指望
mainClass写成com.example.Outer$Inner来“直接启动内部类”——Java 规范不允许，会报NoClassDefFoundError - 确保
launch.json中projectName字段明确指向包含该内部类的 Maven/Gradle 模块（多模块项目中尤其关键） - 如果内部类在测试包里（
src/test/java），检查launch.json是否遗漏了classPaths或modulePaths，默认只扫src/main
匿名内部类和 Lambda 表达式里的断点特别容易失效
匿名内部类编译后生成形如 Outer.class 的文件，Lambda 更是被编译成桥接方法（lambda$xxx<p>匿名内部类编译后生成形如 <code>Outer$1.class 的文件，Lambda 更是被编译成桥接方法（lambda$xxx$0），行号映射极易错乱。VSCode 调试器对这类结构的源码定位能力弱于 IntelliJ，尤其当代码被重构或增量编译不完整时。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 避免在 Lambda 参数列表或方法引用（
String::length）里设断点——这些位置没有对应源码行，调试器无法绑定 - 把逻辑抽到普通方法里再调用，例如把
list.forEach(x -> process(x))改成list.forEach(this::process)，断点设在process方法内 - 确认 JDK 版本 ≥ 11，低版本 JVM 对 Lambda 行号表支持不全；若用 JDK 17+，检查是否禁用了
--enable-preview（某些预览特性会影响调试符号生成）
内部类访问外部类私有成员时，断点跳过可能是 JIT 优化所致
当内部类频繁访问外部类的 private 字段或方法，HotSpot JVM 可能在运行时内联这些调用，导致字节码与源码行号脱节。此时断点看似加对了，实际执行流已绕过原始位置。
立即学习“Java免费学习笔记（深入）”；
- 临时添加 JVM 参数
-XX:-OmitStackTraceInFastThrow和-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints抑制激进优化（仅开发环境用） - 在外部类字段上加
final或改用包级访问（package-private），减少 JVM 插入桥接方法的必要性 - 观察 Debug 控制台输出的线程栈 —— 如果看到
at com.example.Outer$Inner.xxx(Outer.java:42)但第 42 行根本不是你设断点的位置，说明行号表被破坏，必须重新mvn clean compile
target/classes 下有对应 $ 命名的 class 文件，再验证 mainClass 和 projectName 是否覆盖到该模块，最后关掉 JIT 看是否恢复。 
