问题描述及排查过程
一个正常响应里，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: errcheckreturn err}return nil
}
可以看到如果序列化过程有任何错误，就会中断请求并且设置状态码为400.
ShouldBind方法就没有这个限制了。
解决方案
一是加好err判断，如果反序列化失败，不管是哪个字段失败了，都立刻返回错误。而且建议状态码为400，更清晰。
如果业务要求全都返回http.StatusOK（200），那么这个BindJSON一定会将状态码改写为400，这时候就要看这个不符合要求的请求体是什么情况了，
如果能接受非法请求体，或者要求全部返回200状态码，就用ShouldBind（不推荐），它不会改写状态码
一般情况下，是要拒绝非法请求体的，还是要前端传一个合法的请求体，所以就继续用BindJSON，然后如果出错返回400 bad request就好了。
