从Typescript调用Go后端时出现Go-redis context canceled问题排查

核心问题分析 #

Postman调用正常但前端触发context canceled，大概率是前端请求被提前中断导致后端上下文取消，而非Redis或Go代码本身的问题。前端点击登录后立即重定向，会直接终止未完成的axios POST请求，后端的Redis SET操作依赖请求上下文，自然会抛出该错误。

排查步骤 #

1. 修复前端请求-重定向时机

   • 检查前端代码：是否在发起登录请求后未等待响应就执行了重定向？示例：

     // 错误写法：立即重定向，中断请求
     dispatch(signInAction(credentials));
     history.push('/dashboard');
     
     // 正确写法：在请求成功回调后重定向
     dispatch(signInAction(credentials)).then(() => {
       history.push('/dashboard');
     }).catch(err => {
       // 处理登录失败逻辑
     });
     

   • 确认axios请求是否配置了cancelToken，是否有其他逻辑提前取消了请求。

2. 验证Redis操作的上下文传递

   • 在Go代码的signIn函数中添加日志，确认上下文是否被提前取消：

     func signIn(w http.ResponseWriter, r *http.Request) {
       // ... 前置业务逻辑
       log.Printf("Redis SET前：context状态=%v", r.Context().Err())
       err := redisClient.Set(r.Context(), key, refreshToken, refreshExpiry).Err()
       log.Printf("Redis SET后：context状态=%v", r.Context().Err())
       if err != nil {
         log.Printf("写入refresh token失败：%v", err)
         // 错误处理
       }
       // ... 后续响应逻辑
     }
     

   • 如果日志显示Redis操作前上下文已被取消，可实锤是前端提前终止了请求。

3. 排查CORS配置问题

   • 前端存在OPTIONS预检请求，检查后端CORS中间件配置：
     • 是否允许前端的Origin域名？
     • 是否允许Content-Type等必要请求头？
     • 是否正确处理OPTIONS请求（直接返回200，无需执行业务逻辑）？
   • 错误的CORS配置可能导致浏览器中断POST请求，间接触发上下文取消。

4. 确认Redis服务连通性

   • 验证Docker-compose中Go服务与Redis的网络连通性：
     • 进入Go服务容器，执行ping redis（假设Redis服务名为redis），检查网络可达性。
     • 查看Redis容器日志，确认无连接拒绝、超时等异常记录。

临时应急方案（不推荐长期使用） #

若需快速验证业务逻辑正确性，可给Redis SET操作绑定独立上下文，脱离请求上下文的取消影响，但会导致前端中断请求后后端仍生成无效refresh token：

// 使用独立上下文，不受请求取消影响
ctx := context.Background()
err := redisClient.Set(ctx, key, refreshToken, refreshExpiry).Err()

内容的提问来源于stack exchange，提问作者Deffo