Gin中间件不适合做统一BSON响应，因其无法可靠捕获已写入的JSON响应体进行二次编码，且BSON需显式设置Content-Type、手动写入二进制流，强行在中间件中处理易触发多次WriteHeader panic，并破坏响应生命周期。
Gin 默认不支持 BSON 响应，也没有内置中间件能“自动把 JSON 转成 BSON”——BSON 是二进制格式，必须显式编码、设置 Content-Type: application/bson，且前端几乎无法直接消费。强行在中间件里统一做 BSON 格式化，既无实际场景支撑，又会破坏 Gin 的响应生命周期。
为什么 Gin 中间件不适合做统一 BSON 响应
中间件作用于请求处理链中，但响应体（c.Writer）一旦写入就不可逆；BSON 编码需完整数据结构 + 二进制序列化，而中间件无法可靠捕获 handler 已写入的 JSON 内容再转 BSON——它不是装饰器，不能“后置修改响应体”。常见错误包括：
- 试图读取
c.Writer内容失败（Gin 的ResponseWriter不支持 rewind） - 在中间件里调用
bson.Marshal()后重复写响应，触发http: multiple response.WriteHeader calls - 未设置
Content-Type: application/bson，导致客户端按 JSON 解析二进制流，直接报错
真要返回 BSON，该在哪层做
必须在 handler 内部显式控制，而不是靠中间件“兜底”。BSON 通常只用于特定 RPC 场景（如内部服务间通信），而非对外 API。正确做法是：
- 定义专用 handler 函数，比如
BsonResponse(c *gin.Context, data interface{}) - 用
go.mongodb.org/mongo-driver/bson包编码：buf, _ := bson.Marshal(data) - 手动设置 header：
c.Header("Content-Type", "application/bson") - 直接写入二进制：
c.Writer.Write(buf)，并确保不再调用c.JSON或其他写响应方法 - HTTP 状态码需单独设：
c.Status(http.StatusOK)，因为Write()不自动带状态
用中间件统一格式？选 JSON，别碰 BSON
如果你的目标是“统一响应结构”，JSON 才是标准路径。BSON 不解决字段一致性问题，反而引入编码兼容性、调试困难、工具链断裂等新问题。已验证的稳定方案是：
- 定义
Response结构体（含Code、Message、Data、Timestamp） - 封装
Success(c *gin.Context, data any)和Fail(c *gin.Context, code int, msg string) - 所有 handler 显式调用这些函数，**禁止在
defer中调用**，末尾加return - 若需多格式支持（如同时提供 JSON/BSON），应在路由层分流，例如
GET /api/users.jsonvsGET /api/users.bson，而非中间件自动识别
真正容易被忽略的是：BSON 响应无法被 Gin 的 Recovery 中间件或自定义错误中间件捕获处理——那些中间件默认只适配 c.AbortWithStatusJSON()。一旦 handler 里 BSON 编码出错（比如传了不支持的类型），panic 就会裸奔出去，连错误提示都变成二进制乱码。
