Gin上下文通道传数据异常：超时中间件告警与通道无接收问题

核心问题1：通道重复读取导致阻塞 #

你的中间件里，select的第一个case先读取了通道一次（<-resChan），紧接着又尝试读取第二次（res := <-resChan）。无缓冲通道每次只能传递一个值，第二次读取会因为没有数据而阻塞，导致无法正常获取处理器发送的响应数据。

核心问题2：处理器直接写入响应引发Headers警告 #

在Register函数中，当ShouldBind失败时，你直接调用ctx.JSON写入响应，这会提前把Headers发送给客户端。后续如果触发超时或者中间件尝试写入响应，就会出现Headers were already written的警告。

核心问题3：无缓冲通道发送阻塞风险 #

使用无缓冲通道时，如果处理器发送数据时，中间件已经因为超时进入ctx.Done()分支，发送操作会永久阻塞，造成goroutine泄漏。

修复后的代码 #

1. 修正超时中间件 #

func Timeout(timeout time.Duration) gin.HandlerFunc {
    return func(c *gin.Context) {
        ctx, cancel := context.WithTimeout(c.Request.Context(), timeout)
        defer cancel()

        c.Request = c.Request.WithContext(ctx)

        // 使用带缓冲的通道，避免发送阻塞
        resChan := make(chan ResponseData, 1)

        go func() {
            defer close(resChan) // 确保goroutine退出时关闭通道
            c.Set(ResChan, resChan)
            c.Next()
        }()

        select {
        // 直接在case中接收通道数据，避免重复读取
        case res, ok := <-resChan:
            if !ok {
                // 通道关闭但无数据，说明handler没有发送响应，可能是提前返回了
                return
            }
            if res.Error != nil && res.Error != context.DeadlineExceeded {
                c.JSON(res.StatusCode, response.ErrorResponse(res.Error))
            } else {
                c.JSON(res.StatusCode, response.SuccessResponse(res.Message, res.Data))
            }
        case <-ctx.Done():
            if ctx.Err() == context.DeadlineExceeded {
                err := errors.New("Service is unavailable or timed out")
                // 先检查Headers是否已写入，避免警告
                if !c.Writer.Written() {
                    c.JSON(http.StatusGatewayTimeout, response.ErrorResponse(err))
                }
                c.Abort()
            }
        }
    }
}

2. 修正处理器逻辑 #

func (h *AuthHandler) Register(ctx *gin.Context) {
    reqCtx := ctx.Request.Context()
    resChan := ctx.MustGet(middleware.ResChan).(chan middleware.ResponseData)

    var req request.RegisterRequest
    if err := ctx.ShouldBind(&req); err != nil {
        // 不再直接写入响应，改为发送到通道
        select {
        case resChan <- middleware.ResponseData{
            StatusCode: http.StatusBadRequest,
            Error:      err,
        }:
        default:
            // 通道已满或已关闭，直接丢弃，避免阻塞
        }
        return
    }

    arg := entity.Admin{
        Name:     req.Name,
        Email:    req.Email,
        Password: req.Password,
    }

    result, err := h.authService.Register(reqCtx, arg)

    if err != nil {
        select {
        case resChan <- middleware.ResponseData{
            StatusCode: http.StatusInternalServerError,
            Error:      err,
        }:
        default:
        }
        return
    }

    select {
    case resChan <- middleware.ResponseData{
        StatusCode: http.StatusCreated,
        Message:    "Registration completed successfully.",
        Data:       response.NewAdminResponse(result),
    }:
    default:
    }
}

关键修复点说明 #

• 通道读取逻辑：将select的case改为直接接收数据（res, ok := <-resChan），避免重复读取导致的阻塞。
• 缓冲通道：使用带缓冲的通道（make(chan ResponseData, 1)），降低发送阻塞的概率；同时在发送时用select+default分支，确保即使通道不可用也不会阻塞goroutine。
• 避免提前写入响应：处理器中所有响应都通过通道发送，不再直接调用ctx.JSON，从根源解决Headers已写入的警告。
• 超时分支检查Headers状态：在超时处理时，先通过c.Writer.Written()判断Headers是否已发送，再决定是否写入超时响应。

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