当前位置：首页 > article >正文

go-gin响应被覆盖为400，即使正常返回

article 2024/9/21 8:35:01

问题描述及排查过程

一个正常响应里，http状态码为400，但实际已经成功返回了数据，且无论是自己写的业务逻辑代码还是中间件都没有返回400（bad request）这个状态码。

而且gin debug日志中也提示说有操作试图将状态码400覆盖为200，这个操作肯定就是我们的正常业务响应了，那么这个400状态码是哪里来的呢？

答案是gin框架，因为在json unmarshal的时候有一个字段出错了，但是其他字段是可以正常使用的，而后面的业务逻辑中又没有使用这个没成功反序列化的字段，所以响应一直都是正常的。

接收前端请求的代码如下

func PostProj(c *gin.Context) {
	dto := PostReq{}
    // _ = c.BinJSON(&dto) 原来并没有判断错误，如果有err，还是会正常执行，而且出错的字段没有被业务逻辑使用到，一切就会很正常
	if err := c.BindJSON(&dto); err != nil {
		logrus.Error(err)
		c.JSON(http.StatusOK, HttpRespBody{
			Code: http.StatusBadRequest,
			Msg:  "",
		})
		return
	}
    ...
}

但是BindJSON这个方法使用了MustBindJSON，要求更严格，

// BindJSON is a shortcut for c.MustBindWith(obj, binding.JSON).
func (c *Context) BindJSON(obj any) error {
	return c.MustBindWith(obj, binding.JSON)
}

// MustBindWith binds the passed struct pointer using the specified binding engine.
// It will abort the request with HTTP 400 if any error occurs.
// See the binding package.
func (c *Context) MustBindWith(obj any, b binding.Binding) error {
	if err := c.ShouldBindWith(obj, b); err != nil {
		c.AbortWithError(http.StatusBadRequest, err).SetType(ErrorTypeBind) // nolint: errcheck
		return err
	}
	return nil
}