Echo中设置响应头唯一可靠方式是handler内调用c.Response().Header().Set()或Add()，必须在c.JSON()/c.String()等写响应前执行，否则无效；Set()覆盖同名头，Add()追加值，全局加头应使用e.Pre()注册中间件。
echo.Context.Response().Header().Set() 是唯一可靠方式
在 Echo 中设置响应头，不能靠中间件全局塞、也不能用 e.Use() 拦截改写，必须在 handler 内调用 c.Response().Header().Set() 或 Add()。这是 net/http 原生机制决定的——Response.Header 是一个 map[string][]string，只有在写入前修改才生效；一旦 c.JSON() 或 c.String() 调用后触发 WriteHeader，再 Set 就完全无效（且无报错）。
常见错误现象是：代码里写了 c.Response().Header().Set("X-Trace-ID", traceID)，但浏览器或 curl 看不到这个 header。原因通常是它被写在了 c.JSON() 之后，或者被某个中间件提前触发了写响应。
-
Set()覆盖同名 header 的所有值，Add()追加新值（适合如Link这类允许多值的 header） - 标准 header 如
Content-Type、Content-Length不建议手动 Set，c.JSON()等方法已自动设置；强行覆盖可能导致 Content-Type 错乱或 gzip 失效 - 自定义 header 名推荐用
X-前缀（如X-Request-ID），避免和未来 HTTP 标准冲突
需要全局加 Header？用 e.Pre() + 自定义中间件，但别碰 c.Response().WriteHeader()
如果每个接口都要加 X-Frame-Options: DENY 或 Cache-Control: no-store，可以写一个中间件，但必须注意执行时机：它得在路由匹配后、handler 执行前注入 header，且不能触发实际响应。
正确做法是把 header 设置逻辑放在中间件函数体开头，且确保不调用任何会触发写响应的方法（比如 c.NoContent()、c.String()、c.JSON()）。
- ✅ 正确：
c.Response().Header().Set("X-Frame-Options", "DENY")放在中间件第一行 - ❌ 错误：中间件里写了
return c.String(401, "Unauthorized")—— 这会立即写响应，后续 handler 无法再改状态码或 body - ⚠️ 注意：
e.Use()注册的中间件默认在 handler 之后执行（即 defer 行为），要全局加 header 必须用e.Pre()注册，否则顺序反了
为什么 http.Get/Post 不能设请求 Header？Echo 里也一样
这个问题常被混淆：用户想“给下游服务发请求时带自定义 header”，却去翻 Echo 的响应头文档。其实这是两个方向——Echo 的 c.Response().Header() 控制的是「本服务返回给客户端的 header」；而「本服务作为客户端发请求时带的 header」，跟 Echo 框架无关，只取决于你用的 http.Client。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
也就是说：你在 handler 里调用 http.Get()，它根本没法设 header；必须用 http.NewRequest() + client.Do() 才行。
- ❌
http.Get("https://api.example.com")：Header 完全不可控 - ✅
req, _ := http.NewRequest("GET", "https://api.example.com", nil); req.Header.Set("Authorization", "Bearer xxx") - Echo 的
echo.HTTPErrorHandler或日志中间件里若需透传原始请求 header 到下游，也得走这套流程，不是靠c.Request().Header直接塞过去
Content-Type 和 time.Time 字段容易踩坑
当用 c.JSON() 返回 struct 时，time.Time 默认序列化成 RFC3339 字符串（带时区），但前端常期望 Unix 时间戳或去掉时区的格式。这不是 header 问题，但会连带影响 Content-Type 表现——如果你手动 Set("Content-Type", "application/json; charset=utf-8")，又没处理好 time 字段，JSON 就可能解析失败。
更稳妥的做法是靠 struct tag 控制序列化行为，而不是动 header：
- 加
json:",string"tag 让 time 输出为字符串（如"2026-10-21T13:46:00+08:00"） - 或实现
MarshalJSON()方法返回 int64 秒级时间戳 - 别在 handler 里手动
c.Response().Header().Set("Content-Type", ...)覆盖c.JSON()的默认行为，除非你明确知道后果（比如要返回application/vnd.api+json）
真正该盯紧的，是 header 设置时机和方向——响应头只在 c.Response() 上设，请求头只在 http.NewRequest() 上设，混用就会静默失效。
