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

问题描述及排查过程

一个正常响应里，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
}

可以看到如果序列化过程有任何错误，就会中断请求并且设置状态码为400.

ShouldBind方法就没有这个限制了。

解决方案

一是加好err判断，如果反序列化失败，不管是哪个字段失败了，都立刻返回错误。而且建议状态码为400，更清晰。

如果业务要求全都返回http.StatusOK（200），那么这个BindJSON一定会将状态码改写为400，这时候就要看这个不符合要求的请求体是什么情况了，

如果能接受非法请求体，或者要求全部返回200状态码，就用ShouldBind（不推荐），它不会改写状态码

一般情况下，是要拒绝非法请求体的，还是要前端传一个合法的请求体，所以就继续用BindJSON，然后如果出错返回400 bad request就好了。