用 ChatGPT 5.5 辅助后端接口排查：从报错日志到定位思路

文章摘要本文以 ChatGPT 5.5 为例介绍如何在后端接口排查中利用大模型辅助整理日志、分析异常堆栈、区分已确认事实与可能原因并围绕订单创建接口偶发 500、userInfo 为空、ThreadLocal 上下文丢失、鉴权链路异常等问题给出排查路径、日志补充建议和防御性代码思路。同时提到可通过 KULAAI 快速访问 ChatGPT、Claude、Gemini 等模型降低部署和调试成本。最近在做接口联调和线上问题排查时一个很明显的感受是后端开发真正耗时间的往往不是写某一段业务代码而是在一堆日志、异常堆栈、接口参数、数据库状态之间来回切换。尤其是线上偶发问题日志看起来都有信息但要把它们串成一条完整的定位路径还是很费脑子。现在很多开发者会把 ChatGPT、Claude、Gemini 这类大模型工具放进日常开发流程里用来辅助分析日志、整理排查步骤、生成测试用例和复盘文档。我自己也对比过自研部署、开源 UI 和一些第三方聚合平台。实际用下来如果只是想在国内环境里快速试用多种模型而不是花时间折腾部署和接口配置KULAAIhttps://ouai.me这类一站式集成工具会比较省事。它集成了 Gemini、ChatGPT、Claude 等主流模型适合个人日常测试也适合小项目快速验证想法。本文主要围绕 ChatGPT 5.5 展开聊一个更贴近日常开发的场景如何用它辅助分析后端接口异常把零散报错整理成可执行的排查路径。需要提前说明一点这里说的“辅助排查”不是让 ChatGPT 5.5 直接替你判断线上故障原因。线上问题最终还是要靠日志、监控、链路追踪、数据库状态和复现实验来确认。大模型更适合做的是帮你整理信息、补全排查清单、发现容易遗漏的方向并把一堆杂乱内容转成结构化分析。一、问题背景一个接口偶发 500假设现在有一个很常见的后端接口httpPOST /api/order/create接口功能是创建订单流程大致如下校验用户登录状态查询商品库存创建订单记录扣减库存写入订单日志返回订单号。最近联调时发现这个接口偶尔返回 500。不是每次都失败而是在并发稍微高一点的时候更容易出现。接口返回json{ code: 500, message: Internal Server Error, data: null }服务端日志里可以看到类似内容2026-01-15 10:23:41.231 ERROR [order-service] c.e.order.controller.OrderController : create order failed java.lang.NullPointerException: Cannot invoke com.example.user.UserInfo.getUserId() because userInfo is null at com.example.order.service.OrderService.createOrder(OrderService.java:86) at com.example.order.controller.OrderController.create(OrderController.java:42)相关代码简化如下PostMapping(/create) public ResultString create(RequestBody CreateOrderRequest request) { String orderNo orderService.createOrder(request); return Result.success(orderNo); }public String createOrder(CreateOrderRequest request) { UserInfo userInfo userContext.getCurrentUser(); Long userId userInfo.getUserId(); Product product productMapper.selectById(request.getProductId()); if (product.getStock() 0) { throw new BizException(库存不足); } Order order new Order(); order.setUserId(userId); order.setProductId(product.getId()); order.setAmount(product.getPrice()); orderMapper.insert(order); productMapper.decreaseStock(product.getId()); return order.getOrderNo(); }从堆栈看问题似乎很直接userInfo是null。但真实开发里不能看到 NPE 就直接改一行判空了事。更关键的问题是为什么当前接口里拿不到用户信息二、不要直接问“这是什么问题”很多人使用大模型时会这样问下面代码报空指针帮我看看原因。这种问法不是不能用但模型大概率会回答userInfo为空需要判空检查登录态检查 token增加异常处理。这些建议没错但比较浅。更好的问法是把日志、代码、背景和你希望的输出形式一起给它。可以这样问 ChatGPT 5.5你是一名 Java 后端问题排查助手。下面是一个订单创建接口的异常日志和简化代码。 请你帮我完成 1. 只基于已给信息整理问题现象 2. 区分“已确认事实”和“可能原因” 3. 给出排查优先级 4. 不要直接下最终结论 5. 输出适合研发排查记录使用。 【异常日志】 粘贴日志 【相关代码】 粘贴代码 【补充背景】 接口在并发稍高时更容易出现 500单次手动调用不一定复现。这样输入后ChatGPT 5.5 的输出通常会更接近排查记录而不是简单给一句“加判空”。三、让 ChatGPT 5.5 先整理事实比较理想的输出应该类似这样markdown## 已确认事实 1. /api/order/create 接口偶发返回 500。 2. 异常类型为 NullPointerException。 3. 空指针发生在 OrderService.createOrder 方法中。 4. 具体位置是调用 userInfo.getUserId() 时userInfo 为 null。 5. userInfo 来源于 userContext.getCurrentUser()。 6. 问题在并发稍高时更容易出现单次调用不一定复现。 ## 可能原因 1. 当前请求未正确携带登录 token。 2. token 解析失败导致用户上下文未写入。 3. 用户上下文使用了 ThreadLocal但在线程复用或异步场景下没有正确设置。 4. 网关或拦截器在部分请求中没有执行鉴权逻辑。 5. 并发场景下存在上下文污染或清理时机不正确。 6. 测试环境存在部分请求绕过登录态的情况。 ## 暂不能直接确认的部分 1. 不能仅凭 NPE 判断是前端未传 token。 2. 不能确认一定是 ThreadLocal 问题需要查看 userContext 实现。 3. 不能确认是否与异步线程有关需要查看调用链。 4. 不能确认是否所有失败请求都缺少 token需要结合网关日志或 access log。这个结构就比“加个 if 判断”有价值多了。因为实际排查线上问题时第一步不是急着改代码而是先搞清楚确认了什么猜测了什么哪些证据还缺下一步该查哪里。四、继续让它生成排查路径接下来可以继续问请基于上面的事实和可能原因给出一个后端接口排查路径。 要求 1. 从最容易验证、最高优先级开始 2. 每一步说明要看什么 3. 每一步说明目的 4. 不超过 8 步 5. 包含日志、鉴权、ThreadLocal、并发复现几个方向。输出可以整理成这样markdown## 排查路径 ### 1. 确认失败请求是否携带 token - 看什么access log、网关日志、请求 Header。 - 目的确认失败请求是否缺少 Authorization 信息。 ### 2. 查看鉴权拦截器是否执行 - 看什么登录拦截器、Filter、Interceptor 的日志。 - 目的确认请求是否经过统一鉴权流程。 ### 3. 检查 token 解析结果 - 看什么token 是否过期、解析是否异常、用户 ID 是否为空。 - 目的确认是否因为 token 无效导致用户上下文未写入。 ### 4. 检查 UserContext 实现 - 看什么是否基于 ThreadLocal 保存用户信息。 - 目的确认用户上下文是否依赖当前线程。 ### 5. 检查 ThreadLocal 设置和清理时机 - 看什么是否在请求开始时 set在请求结束时 remove。 - 目的避免上下文残留或被提前清理。 ### 6. 检查是否存在异步调用 - 看什么是否使用 Async、线程池、CompletableFuture。 - 目的确认用户上下文是否跨线程丢失。 ### 7. 压测复现并增加关键日志 - 看什么并发请求下 userInfo 为 null 的比例。 - 目的判断问题是否与并发、线程复用有关。 ### 8. 增加接口防御性处理 - 看什么userInfo 为空时是否返回明确的 401/登录失效。 - 目的避免 NPE 暴露为 500同时提升问题可观测性。这个排查顺序比较适合真实项目。它不会一上来就认定“前端没传 token”也不会直接把问题归到 ThreadLocal而是一步步补证据。五、补充一个更合理的接口防御写法从代码上看这里确实应该避免直接调用Long userId userInfo.getUserId();可以先做基本防御public String createOrder(CreateOrderRequest request) { UserInfo userInfo userContext.getCurrentUser(); if (userInfo null || userInfo.getUserId() null) { throw new UnauthorizedException(用户未登录或登录状态已失效); } Long userId userInfo.getUserId(); Product product productMapper.selectById(request.getProductId()); if (product null) { throw new BizException(商品不存在); } if (product.getStock() 0) { throw new BizException(库存不足); } Order order new Order(); order.setUserId(userId); order.setProductId(product.getId()); order.setAmount(product.getPrice()); orderMapper.insert(order); productMapper.decreaseStock(product.getId()); return order.getOrderNo(); }同时配合全局异常处理RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(UnauthorizedException.class) public ResultVoid handleUnauthorized(UnauthorizedException e) { return Result.fail(401, e.getMessage()); } ExceptionHandler(BizException.class) public ResultVoid handleBizException(BizException e) { return Result.fail(400, e.getMessage()); } ExceptionHandler(Exception.class) public ResultVoid handleException(Exception e) { // 这里应记录完整异常堆栈 return Result.fail(500, 系统异常请稍后重试); } }这样做的好处是未登录问题返回 401而不是 500业务异常和系统异常区分开前端能根据状态码做明确处理后端日志也更容易定位问题。不过要注意这只能防止接口继续抛 NPE并不等于根因已经解决。如果用户上下文不应该为空那仍然要继续查鉴权链路和上下文传递。六、重点检查 ThreadLocal 场景很多 Java Web 项目会用 ThreadLocal 保存当前登录用户例如public class UserContext { private static final ThreadLocalUserInfo USER_HOLDER new ThreadLocal(); public static void set(UserInfo userInfo) { USER_HOLDER.set(userInfo); } public static UserInfo getCurrentUser() { return USER_HOLDER.get(); } public static void clear() { USER_HOLDER.remove(); } }拦截器中设置public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); UserInfo userInfo tokenService.parse(token); UserContext.set(userInfo); return true; }请求结束后清理public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); }这种写法本身很常见但有几个坑1. 没有及时 clear如果请求结束后没有remove()线程池复用时可能出现用户上下文残留。这类问题更隐蔽甚至可能造成数据串用户。2. 异步线程拿不到上下文比如CompletableFuture.runAsync(() - { UserInfo userInfo UserContext.getCurrentUser(); // 这里可能是 null });因为 ThreadLocal 只绑定当前线程换了线程就拿不到原来的值。3. 拦截器没有覆盖所有路径有些接口路径可能被配置为白名单或者网关转发时路径变化导致鉴权逻辑没有执行。4. token 解析异常被吞掉如果 token 解析失败后没有中断请求而是继续往下走就可能导致业务层拿到 null。这几个点都很适合让 ChatGPT 5.5 帮忙整理成 checklist然后逐项验证。七、让 ChatGPT 5.5 帮你补日志点排查偶发问题时最怕日志里只有一句 NPE没有上下文。可以继续问针对这个接口偶发 userInfo 为空的问题请帮我设计需要补充的关键日志点。 要求 1. 不打印完整 token 2. 能关联单次请求 3. 包含网关、拦截器、业务层 4. 注意日志不要泄露敏感信息。可以得到类似建议markdown## 建议日志点 ### 1. 网关层 - requestId - path - method - 是否存在 Authorization Header - token 前 6 位 hash 或脱敏标识 - 转发目标服务 ### 2. 鉴权拦截器 - requestId - token 是否存在 - token 解析是否成功 - 解析出的 userId - 是否写入 UserContext ### 3. 业务层入口 - requestId - productId - UserContext 中 userInfo 是否为空 - userId 是否为空 ### 4. 异常日志 - requestId - 接口路径 - 异常类型 - 堆栈 - 当前线程名对应代码中可以使用 MDC 记录 requestIdComponent public class RequestIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String requestId UUID.randomUUID().toString().replace(-, ); MDC.put(requestId, requestId); try { chain.doFilter(request, response); } finally { MDC.remove(requestId); } } }日志格式中带上[%X{requestId}] %-5level %logger - %msg%n这样一次请求从网关、拦截器到业务层都能串起来。八、让它生成压测复现思路如果问题只在并发稍高时出现就不能只靠手动点接口。可以让 ChatGPT 5.5 生成一个简单的压测方案请给出一个针对该接口的并发复现方案。 要求 1. 使用 JMeter 或 curl 都可以 2. 重点观察 userInfo 为空的问题 3. 给出需要记录的指标 4. 不要求复杂压测只用于问题复现。它可能会给出这样的方案markdown## 并发复现方案 ### 测试目标 验证 /api/order/create 在并发请求下是否更容易出现 userInfo null。 ### 请求准备 - 使用同一个有效 token - 使用多个不同商品 ID - 保证测试商品库存充足 - 每个请求带上 requestId。 ### 并发设置 - 线程数10、30、50 逐步增加 - 循环次数每个线程 100 次 - 间隔时间可设置 100ms - 观察错误率变化。 ### 重点记录 - 总请求数 - 500 数量 - 401 数量 - userInfo 为空次数 - token 解析失败次数 - 平均响应时间 - 失败请求 requestId。 ### 判断方向 - 如果 401 增多可能是 token 校验或登录态问题 - 如果 500 仍然出现说明业务层异常处理仍不完整 - 如果 userInfo 为空集中在异步流程重点检查上下文传递 - 如果并发越高越明显重点检查线程池、ThreadLocal 或共享变量。这类输出不是最终方案但能快速给你一个复现框架。九、ChatGPT 5.5 在后端开发里适合做什么结合这个例子我觉得 ChatGPT 5.5 比较适合做这些事情1. 日志整理把 N 段日志合并成问题现象异常位置可能影响范围待确认问题。2. 排查清单生成例如接口 500 排查清单Redis 缓存穿透排查清单MySQL 慢查询排查清单MQ 消息堆积排查清单。3. 代码风险点提示它可以帮你指出一些常见问题空指针事务边界并发安全资源未关闭异常被吞日志不完整。4. 单元测试用例补充例如针对订单接口可以让它生成测试用例未登录商品不存在库存不足正常下单并发下单重复提交。5. 复盘文档生成一次线上问题处理完可以把排查过程丢给它让它整理成问题背景影响范围时间线根因分析修复方案预防措施。十、但不要让它替你拍板需要强调的是大模型在后端排查里也有明显边界。它不适合在缺少日志时直接判断根因替你确认线上数据库状态替你判断某次发布是否一定导致问题在没看完整调用链时给最终结论直接生成未经验证的生产修复代码。尤其是线上故障不能因为模型说“可能是 ThreadLocal”就直接改生产逻辑。正确做法应该是让它帮你整理假设然后你用日志、监控和复现实验去验证。十一、我常用的 Prompt 模板如果你想用 ChatGPT 5.5 辅助后端接口排查可以直接套这个模板你是一名 Java 后端问题排查助手。下面是接口异常信息请帮我整理排查思路。 【接口背景】 接口路径 接口功能 技术栈 是否经过网关 是否需要登录 【异常现象】 1. 2. 3. 【异常日志】 粘贴完整异常日志 【相关代码】 粘贴 Controller / Service / Mapper / 拦截器代码 【补充信息】 是否偶发 是否与并发有关 最近是否发布 是否有监控异常 【输出要求】 1. 先整理已确认事实 2. 再列可能原因 3. 给出排查优先级 4. 每一步说明要看什么日志或证据 5. 不要直接下最终结论 6. 如果信息不足请列出需要补充的内容。这个模板的核心是让模型帮你“拆问题”而不是让它直接“猜答案”。总结ChatGPT 5.5 用在后端开发里比较实用的位置不是替你写几行简单代码而是辅助处理那些信息量大、上下文多、排查链路长的问题。以接口偶发 500 为例它可以帮你从日志中提取关键事实区分已确认现象和可能原因生成排查优先级补充日志设计梳理 ThreadLocal、鉴权、并发等方向整理压测复现思路最后生成问题复盘文档。但最终结论仍然要靠真实证据确认。如果把它当成一个“排查思路整理助手”而不是“线上故障裁判”它在日常开发中的价值会更稳定也更符合真实工程场景。