c.JSON()是最常用且安全的JSON响应方式，自动设置Content-Type、调用json.Marshal序列化并写入响应体，无需手动管理header或状态码；其他方法如JSONPretty、JSONBlob、流式编码仅适用于调试、预序列化或超大数据等特定场景。
c.JSON() 是最常用且安全的 JSON 响应方式
绝大多数场景下，直接用 c.JSON() 就够了。它自动设置 Content-Type: application/json; charset=utf-8，调用 json.Marshal() 序列化，并写入响应体。不需要手动管理 header 或状态码细节。
常见错误是误以为要先调用 c.Response().WriteHeader() 再自己 encode —— 这样容易漏设 header、重复写状态码，还可能因 body 已写入而干扰中间件（比如 Logger）。
-
c.JSON()内部已处理好状态码、header、编码和错误返回，无需额外包裹if err != nil判断（它本身返回error，但 handler 中直接 return 即可） - 结构体字段必须是导出字段（首字母大写），且建议显式加
json:标签，避免零值字段被忽略或命名不一致 - 传入
nil、map[string]interface{}或未初始化的指针会 panic，务必确保目标值非空且可序列化
c.JSONPretty() 仅用于调试，别在生产环境默认启用
c.JSONPretty() 会在输出中加入缩进（如 " "），方便人工阅读，但会增加响应体积、降低吞吐量。它不是“美化开关”，而是明确的独立方法调用。
有人试图通过 URL 参数（如 ?pretty）动态控制格式，但 Echo 不自带该逻辑 —— 必须手动判断并分支调用 c.JSON() 或 c.JSONPretty()。
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 调试时可临时替换：把
c.JSON(200, u)改成c.JSONPretty(200, u, " ") - 若需按 query 动态切换，得自己解析：
if c.QueryParam("pretty") != "" { c.JSONPretty(...) } else { c.JSON(...) } - 注意：缩进字符串不能是空字符串或
\t以外的不可见字符，否则json.MarshalIndent()会报错
避免手撸 JSON 流，除非你真需要流式响应
文档里提到的 “JSON 流” 方式（用 json.NewEncoder(c.Response()).Encode()）本质是绕过 c.JSON() 的封装，直接操作底层 http.ResponseWriter。它不自动设 header，也不做 error 包装，更不会触发 echo 的 write hook（比如压缩中间件）。
这种写法只在两类场景合理：一是响应超大数据集（如导出百万行 JSON Lines），二是需要分块 flush（如 SSE）。普通 API 完全没必要。
- 漏掉
c.Response().Header().Set(echo.HeaderContentType, echo.MIMEApplicationJSONCharsetUTF8)会导致前端解析失败 - 没调用
c.Response().WriteHeader(code)会让 Go 使用默认 200，掩盖真实状态意图 - 一旦开始 write，后续中间件（如 ResponseLogger）可能拿不到完整响应信息
c.JSONBlob() 适合预序列化结果，但要注意内存和安全性
c.JSONBlob() 接收 []byte，跳过运行时序列化。适用于：缓存 JSON 字符串、复用固定响应、或从外部服务拿到已编码数据后透传。
但它把序列化责任完全移交给调用方 —— 比如你传入 json.RawMessage 或第三方库生成的字节，就得确保内容合法、无 XSS 风险、且 UTF-8 编码正确。
- 不要对用户输入直接
json.Marshal()后传给c.JSONBlob()，这和c.JSON()没区别，还多一步转换 - 若 byte slice 来自不可信来源（如数据库 raw 字段），务必验证是否为合法 JSON，可用
json.Valid()快速检查 - 大 blob（>1MB）可能引发 GC 压力，不如用流式或分页
c.JSON()，其余方法都是为特定约束存在的补丁，不是“更高级”的替代品。滥用 JSONPretty 或手写流，反而让代码更难维护、更易出错。 
