AI 辅助 Java 后端调试：让 AI 成为你的调试伙伴

发现问题 → 看报错 → 猜原因 → 加断点 → 重现 → 确认 → 修复

发现问题 → 收集上下文 → AI 推理可能原因 → 针对性验证 → 修复

请帮我分析这个 Java 异常：

【异常类型】
{异常类名}

【完整 Stack Trace】
{粘贴完整的 stack trace}

【相关代码】
{粘贴出错的代码片段}

【环境信息】
- Java 版本：{版本}
- 框架：{Spring Boot 版本等}
- 数据库：{如果有}

请分析：
1. 这个异常的根本原因是什么？
2. 是业务层面的问题还是代码 bug？
3. 最可能的触发场景是什么？
4. 如何修复？请给出具体代码修改。
5. 如何在代码中加入防御性检查，避免再次发生？

我遇到了一个逻辑问题，请帮我分析：

【期望行为】
{描述期望的行为}

【实际行为】
{描述实际发生的行为}

【相关代码】
{粘贴完整的方法/类代码}

【已尝试的方法】
{描述你试过的调试方法}

请分析：
1. 代码中哪里出现了逻辑错误？
2. 为什么这里会出错？（思维链）
3. 如何修复？
4. 有没有类似的模式需要检查整个代码库？

请帮我分析这个并发问题：

【现象描述】
{描述在并发场景下出现的问题}

【相关代码】
{粘贴涉及多线程的代码}

请分析（重点检查以下典型并发反模式）：
1. 共享可变变量是否没有同步？
2. 集合类是否使用了非线程安全的实现（ArrayList/HashMap）？
3. 事务边界是否不当导致数据不一致？
4. 是否存在锁粒度过粗或死锁风险？

如果发现并发问题：
- 最可能的触发条件是什么？
- 如何修复？（优先推荐：ThreadLocal > 原子类 > synchronized > ReentrantLock）
- 如何写测试用例来复现这个问题？

请帮我分析这个性能问题：

【性能数据】
- 问题方法：{方法名}
- 单次耗时：{xxx ms}
- 期望耗时：{xxx ms}
- 调用频率：{QPS 或调用次数}

【慢查询/关键日志】
{paste 慢查询 SQL 或关键日志}

【相关代码】
{粘贴代码}

【JVM 信息】（如果有）
{paste GC 日志或 JStack 线程 dump 关键部分}

请分析：
1. 性能瓶颈最可能在哪个环节？（数据库？CPU？锁竞争？内存？）
2. 导致慢的根本原因是什么？（N+1？全表扫描？锁等待？）
3. 如何优化？（按优先级列出方案）
4. 优化后预期提升多少？
5. 如何写性能测试验证优化效果？

1. Stack trace：完整，不要省略 Caused by 部分
2. 相关代码：出错的方法 + 调用它的地方，不只是一行
3. 环境描述：Java 版本、Spring Boot 版本、数据库版本
4. 复现步骤：如果知道的话（触发条件、频率）

请对比【修复前】和【修复后】的代码：
1. 原问题是否已修复？
2. 是否引入了新问题？
3. 代码风格是否一致？

【修复前】
{paste original code}

【修复后】
{paste fixed code}

基于对这段代码的分析，在关键路径上添加 DEBUG 日志
来辅助定位问题：
- 方法入口/出口
- 分支判断点
- 循环内的关键变量
- 外部调用（数据库、HTTP、Redis）

要求：
- 每个方法最多 3-5 条日志
- 使用 Slf4j：log.debug("methodName | var={}", var)
- 不影响原有逻辑和性能

Spring Boot 应用启动失败，请帮我分析：

【完整报错】
{粘贴启动失败的所有异常 stack trace}

【出错的配置类】
{粘贴报错的配置类或启动类}

请分析：
1. 哪个 Bean 初始化失败了？
2. 根本原因是什么？（循环依赖？配置缺失？类型不匹配？）
3. 如何修复？
4. 如何避免此类问题？（Spring Boot 启动检查建议）

MyBatis 执行 SQL 时报错，请帮我分析：

【报错信息】
{粘贴 MyBatis 相关异常}

【出错的 SQL】
{粘贴出问题的 SQL}

【Mapper 代码】
{粘贴 Mapper XML 或注解}

【实体类相关部分】
{粘贴出错的字段映射部分}

请分析：
1. SQL/映射的哪里有问题？
2. 是参数绑定问题？字段映射问题？还是 SQL 语法问题？
3. 如何修复？

我的 @Transactional 事务没有生效，请帮我分析：

【问题描述】
{描述预期的和实际的事务行为}

【相关代码】
{粘贴包含 @Transactional 的完整方法}

请重点检查以下常见的事务失效原因：
1. 方法内部自调用（this.method()）—— 代理对象问题
2. 非 public 方法—— Spring 事务基于代理，public 以外不代理
3. 异常被 catch 吞掉了—— 事务基于异常回滚，吞异常则不回滚
4. 事务传播行为不当—— REQUIRED vs REQUIRES_NEW 等
5. 方法返回后异步执行了数据库操作—— 异步在线程池执行，不在事务内

如果确认是内部自调用问题：
- 给出通过 ApplicationContext 获取自身代理的最佳方案
- 给出通过 AOP 切面解耦的方案
- 说明为什么 this.method() 不能被代理

请帮我分析这个并发数据竞争问题：

【现象描述】
{描述在并发场景下出现的数据不一致/重复提交等问题}

【涉及共享资源的代码】
{粘贴涉及多线程读写的代码}

【已有的并发控制】
{如果有同步措施，粘贴}

请检查：
1. 哪些变量/资源是共享的？
2. 是否有足够的同步措施？
3. 是否存在典型反模式：
   - DateFormat/SimpleDateFormat 非线程安全
   - HashMap/ArrayList 在多线程中使用
   - Long/Double 等"原子"类型在并发下的复合操作
   - 数据库连接在多线程间共享

修复方案：
- 按优先级推荐方案（ThreadLocal > Atomic > synchronized > ReentrantLock）
- 给出具体代码修改

请帮我分析这个内存问题：

【GC 日志】
{paste GC log}

【JStack 线程 dump 关键部分】
{paste 线程dump 中 BLOCKED/WAITING/TIMED_WAITING 的线程}

【堆内存使用情况】
{paste jstat -gc 等输出}

【问题描述】
{描述 OOM 发生的时机、频率、进程重启情况}

请分析：
1. 内存使用趋势是什么？（持续增长？周期性变化？）
2. 是否有内存泄漏的迹象？
3. 最可能的泄漏点在哪里？
4. 如何定位具体的泄漏对象？（给出 jmap/ MAT 分析的建议）
5. 短期应急方案和长期修复方案分别是什么？

基于以上根因分析，请生成一个 JUnit 5 测试用例来复现这个 Bug。

要求：
1. 使用 @ParameterizedTest 测试多组边界数据
2. 包含清晰的 @DisplayName 说明测试场景
3. 测试必须能稳定复现问题（不是有时成功有时失败）
4. 断言要精确（不只是 assertNotNull，要检查具体的值和状态）

格式：
```java
@DisplayName("场景描述")
@ParameterizedTest
@CsvSource({
    "输入1, 期望1",
    "输入2, 期望2"
})
void testName(String input, String expected) {
    // given
    // when
    // then
}

### 进阶二：AI 自动生成防御性代码

让 AI 在修复后加上防御性措施：

针对这个并发问题，请帮我写一个 chaos 测试用例：
- 使用 ExecutorService 模拟并发场景
- 多次执行（100+ 次）来提高复现概率
- 在 CI 中可以稳定失败（发现问题就 FAIL）

使用 JUnit 5 + AssertJ：
```java
@Test
@DisplayName("并发场景：Xxx 问题")
void testXxxUnderConcurrency() throws InterruptedException {
    // given: 准备测试数据
    // when: 多线程并发执行
    // then: 断言最终状态正确
}

---

## 📋 调试 Prompt 检查清单

每次用 AI 调试前，对照这个清单检查上下文是否充足：