直接在每个 handler 里写 c.json() 会导致响应格式不一致，因状态码、code、message、data 全靠手写，且 panic、校验失败等错误路径未统一处理；需用中间件拦截成功响应并重写 json 结构，配合全局错误中间件和 apperror 统一错误响应，同时显式设置 content-type: application/json; charset=utf-8。
为什么直接在每个 handler 里写 c.JSON() 会导致响应格式不一致
因为每个 handler 自行调用 c.JSON() 时，状态码、code 字段、message 内容、data 包裹方式全靠手写——有人返回 {"status":200,"msg":"ok","result":{}}，有人写 {"code":0,"message":"success","data":null}，前端必须写 N 种解析逻辑。更糟的是，panic、校验失败、数据库错误等路径根本没走这个逻辑，直接抛出裸错误或 500 HTML 页面。
用中间件拦截所有成功响应并重写输出
不能依赖 c.JSON() 的默认行为，得在响应真正写出前劫持它。Echo 提供 c.Response().Writer 替换机制，配合自定义 ResponseWriter 拦截 Write() 和 WriteHeader() 调用：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 只对
Content-Type: application/json且状态码为 2xx 的响应做包裹，避免影响静态文件、重定向或错误页 - 读取原始响应体（需用
bytes.Buffer缓存），反序列化后套进标准结构：{"code":0,"message":"success","data":...} - 手动调用
c.Response().Writer.WriteHeader()设置真实 HTTP 状态码，再写入新 JSON - 务必在中间件里检查
c.Response().Committed—— 若已提交（比如之前有c.String()或 panic 恢复中间件提前写了响应），跳过处理，否则会 panic
怎么让错误也走同一套响应结构
成功响应靠拦截 Write，错误响应得靠另一层：全局错误中间件 + 统一 AppError 类型。不要用 panic 或裸 http.Error：
- 定义
type AppError struct { Code int `json:"code"` Message string `json:"message"` HTTPStatus int `json:"-"` } - 在业务 handler 中主动返回
return echo.NewHTTPError(e.HTTPStatus, e)，这样会进入 Echo 的错误处理链 - 注册错误中间件：
e.HTTPErrorHandler = func(err error, c echo.Context) {...}，里面统一调用c.JSON(e.HTTPStatus, e)，确保和成功响应结构一致 - 注意：验证失败（
c.Validate()）默认返回 400 且不带code字段，需在HTTPErrorHandler里识别*echo.HTTPError并重写
别漏掉 Content-Type 和字符编码
即使你把 JSON 包裹好了，如果没显式设置 header，前端可能收到 text/plain 或乱码：
-
c.JSON()确实会设Content-Type: application/json; charset=UTF-8，但你用自定义 writer 手动Write()时，这步被绕过了 - 必须在写入前调用
c.Response().Header().Set("Content-Type", "application/json; charset=utf-8") - 若响应体含中文，
charset=utf-8缺失会导致前端显示 符号，尤其在 iOS Safari 上更敏感 - 不要写
charset=UTF-8（大写），部分旧版 nginx 会忽略；统一用小写utf-8
c.JSON() —— 一旦有人绕过，整套格式就破防了。建议把 c.JSON() 封装成私有方法，或用 linter 规则禁止直接调用。
