直接在路由里加header不起作用，是因为Echo路由处理器不处理OPTIONS预检请求且跨域属横切关注点，必须用e.Use()注册中间件统一拦截并响应；若前端带credentials，Access-Control-Allow-Origin不能为*，须指定具体域名。
为什么直接在路由里加 header 不起作用
Echo 的路由处理函数（比如 e.GET() 里的闭包）只负责业务响应，不自动拦截 OPTIONS 预检、也不统一注入跨域头。如果你只在某个 handler 里写 w.Header().Set("Access-Control-Allow-Origin", "*")，那只有该路由生效；而浏览器发 OPTIONS 时根本进不到这个 handler，直接 404 或 405，后续请求卡死。
必须用中间件统一处理 OPTIONS 和响应头
跨域逻辑属于横切关注点，得在请求进入业务逻辑前就完成预检响应和头设置。Echo 官方推荐方式是注册一个 CORS 中间件，覆盖所有路由（包括未定义的 OPTIONS）。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 中间件必须在
e.Use()中注册，且放在所有e.GET()/e.POST()之前 - 对
OPTIONS请求要立即返回 204 或 200，且不能有任何 body（连换行都不能有） -
Access-Control-Allow-Origin和Access-Control-Allow-Credentials: true不能共存于*，否则浏览器静默丢弃响应 - 如果前端带了
credentials: 'include'，后端必须写具体域名，比如"https://admin.example.com"
func corsMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
req := c.Request()
res := c.Response()
origin := req.Header.Get("Origin")
if origin != "" {
res.Header().Set("Access-Control-Allow-Origin", origin)
res.Header().Set("Vary", "Origin")
res.Header().Set("Access-Control-Allow-Credentials", "true")
}
res.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
res.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Requested-With")
if req.Method == "OPTIONS" {
return c.NoContent(http.StatusOK) // 注意：不能用 c.String() 或 c.JSON()
}
return next(c)
}
}
// 注册顺序很重要
e.Use(corsMiddleware)
e.GET("/api/users", handler)
e.POST("/api/login", handler)
用第三方库 echo/middleware/cors 更省事但要注意配置陷阱
官方维护的 echo/middleware/cors 封装了常见逻辑，但默认配置不兼容带凭证的请求——它会把 AllowOrigins 设为 []string{"*"}，而一旦你设了 AllowCredentials: true，就会触发浏览器报错 “The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'”。
- 必须显式指定
AllowOrigins为具体域名切片，不能留空或只写* -
AllowCredentials默认是false，开启前务必同步改AllowOrigins - 开发环境可临时用
AllowOrigins: []string{"http://localhost:3000"}，生产环境建议从配置或环境变量读取 - 别漏掉
AllowHeaders，否则自定义 header（如Authorization）会被浏览器拦截
e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
AllowOrigins: []string{"https://admin.example.com"},
AllowCredentials: true,
AllowHeaders: []string{"Content-Type", "Authorization"},
}))
调试时最容易忽略的两个硬性条件
就算中间件代码完全正确，以下两点任一不满足，CORS 依然失败：
-
header()类操作必须在任何输出前执行——Echo 的c.Response().Header().Set()是安全的，但如果你在中间件或 handler 里提前调用了fmt.Println()、log.Printf()或任何写入os.Stdout的操作，且没重定向日志输出，就可能触发 Go 的http: superfluous response.WriteHeader警告，导致部分 header 丢失 - 反向代理（如 Nginx、Apache）可能缓存了不含 CORS 头的响应，尤其是没配
Vary: Origin时。CDN 或代理层覆写了响应头，本地测试通了，上线就失效
