在HTTP服务调用其他服务时是否应复用context对象？

首先你的猜测是对的：当客户端取消请求（比如关闭连接、请求超时），http.Request携带的context会被触发取消，这时候你传给DynamoDB的QueryWithContext的context也会跟着取消，导致返回context canceled错误。

关于是否复用请求context，结论是：大部分场景下应该复用请求的context，只有少数特殊情况需要新建，具体原因和场景如下：

为什么应该复用请求context #

• 请求生命周期对齐：请求的context天然绑定了请求的生命周期，当请求被取消或超时，下游的DynamoDB调用也应该随之终止，避免做无用功——比如客户端已经不需要结果了，还让DynamoDB执行查询，浪费云资源和成本。
• 元数据传递：请求context可以用来传递请求级别的元数据（比如分布式追踪ID、用户身份信息），下游服务（包括DynamoDB的SDK）可以利用这些信息做日志、追踪，方便排查问题。

为什么会出现context canceled错误 #

这个错误本质是预期行为，常见触发场景包括：

• 客户端提前断开连接（比如用户刷新网页、前端API调用超时中断）
• 服务端设置了请求超时（比如用http.TimeoutHandler），超时后context被取消
• 你的业务逻辑处理太慢，导致请求还没处理完，客户端已经失去耐心断开了

什么时候需要新建context #

只有当你需要脱离请求生命周期执行任务时，才需要新建context，比如：

• 异步任务：请求返回后，需要在后台继续执行的操作（比如日志上报、数据异步归档），这时候应该基于context.Background()或context.TODO()新建，并自己管理超时/取消逻辑。
• 必须完成的操作：某些DynamoDB操作（比如关键数据的写入）必须执行完成，不受请求取消影响，这时候可以新建context，但要注意手动设置超时，避免资源泄漏。

新建context的示例代码：

// 基于后台context新建，设置10秒超时
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel() // 必须调用cancel释放资源
ctx = context.WithValue(ctx, myKey, myVal)

input := &dynamodb.QueryInput{
   // ...
}

result, err := dbclient.QueryWithContext(ctx, input)

优化建议 #

如果你觉得context canceled错误过多，可以做以下优化：

1. 排查请求取消原因：通过日志记录请求的处理时长、客户端断开的时机，看是业务处理太慢还是客户端频繁取消。
2. 给DynamoDB调用单独设置超时：基于请求context派生一个带超时的子context，既保留请求取消的信号，又避免DynamoDB调用无限等待：

   ctx := request.Context()
   // 给DynamoDB查询设置3秒超时
   ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
   defer cancel()
   ctx = context.WithValue(ctx, myKey, myVal)
   
   input := &dynamodb.QueryInput{
      // ...
   }
   
   result, err := dbclient.QueryWithContext(ctx, input)
   

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