Context支持6种原生响应格式，最常用JSON和File，其余需注意MIME类型与编码细节：String()返回text/plain，HTML()返回text/html但不自动设类型，JSON()性能适中而JSONPretty()仅限调试，XML()无声明，File()需校验路径安全，Redirect()要求URL合法，所有响应方法均返回error须检查。
Context 支持 6 种原生响应格式，覆盖纯文本、HTML、JSON、XML、文件流和重定向场景；但 JSON 和 File 最常用，其余需注意 MIME 类型和编码细节。
纯文本与 HTML 响应：用 String() 和 HTML() 时别漏设状态码
两者都接受 code int 参数，但新手常直接传 200 而非 http.StatusOK，虽能运行，却降低可读性与维护性。更关键的是：HTML() 不自动设置 Content-Type: text/html —— 实际测试中若服务端未显式声明，某些旧版浏览器或代理可能降级为 text/plain 渲染。
-
String()返回text/plain; charset=utf-8，适合调试日志、简单 API 返回（如健康检查） -
HTML()返回text/html; charset=utf-8，仅适用于极简内联 HTML（如OK），不推荐用于复杂页面 —— 应该用模板引擎 +HTMLBlob()或自定义渲染器 - 若返回含中文的 HTML 字符串，确保字符串本身是 UTF-8 编码；Go 源文件默认 UTF-8，但从外部读取时需校验
JSON 响应：三种方式性能与可读性差异明显
JSON() 是最常用方式，但它内部调用 json.Marshal()，对大结构体或高频调用会产生内存分配压力；而 JSONPretty() 仅在调试阶段有用，生产环境必须禁用 —— 它会显著拖慢吞吐量且增加响应体积。
-
JSON(code, i)：适合中小数据量，自动设Content-Type: application/json; charset=utf-8 -
JSONPretty(code, i, " ")：仅限开发期手动触发，或配合?pretty查询参数（需启用echo.HTTPError处理逻辑） - 流式 JSON（
json.NewEncoder(c.Response()).Encode()）：绕过中间字节切片，适合大数据量（如导出用户列表），但需手动写 header 和 status code - 注意：结构体字段标签中的
json:"-"或json:",omitempty"仍生效，无需额外处理
XML 与文件响应：XML() 默认不带声明，File() 路径需校验合法性
XML() 函数生成的是纯 XML 内容，不含 声明；客户端解析时通常无碍，但某些强校验系统（如银行对接接口）会报错。而 File() 看似简单，实际最容易因路径拼接引入安全风险。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
XML()返回application/xml; charset=utf-8，结构体需有xmltag，例如Name string `xml:"name"` -
File(path string)会自动推断 MIME 类型（v4.12+），但path必须是绝对路径或经filepath.Clean()处理后的安全路径，否则可能被../绕过读取敏感文件 - 视频/大文件服务务必用
File()，不要用HTMLBlob()或读取全部内容再返回 —— 否则 OOM 风险极高 - 如果需要自定义 HTTP 头（如
Cache-Control），应在File()前调用c.Response().Header().Set()
重定向与错误响应：别把 Redirect() 当万能跳转
Redirect() 只做 3xx 状态码跳转，不处理目标 URL 的协议、域名或路径合法性；它不会自动添加 https:// 前缀，也不会校验相对路径是否越界。同时，error 类型响应（如 HTTPError）默认走全局错误处理器，但若中间件中提前写了 header，可能触发 “write after write” panic。
-
Redirect(code, url string)中url必须是完整 URL（含协议）或合法相对路径（如/login），不能是用户输入未过滤的值 - 常见误用：在中间件里调用
c.Redirect(http.StatusFound, "/login")后没return，导致后续 handler 仍执行并 panic - 自定义错误响应建议用
c.JSON(code, map[string]string{"error": msg})，而非直接panic()或裸写http.Error() -
NoContent()和String(204, "")效果一致，但前者语义更清晰，且不写响应体
真正容易被忽略的是：所有响应方法（String、JSON 等）都**返回 error**，但多数人只关注业务逻辑，忘了检查这个 error —— 它可能来自底层 write 失败（如客户端已断连），尤其在长连接或移动网络环境下，不处理会导致 goroutine 泄漏。
