必须用echo/middleware.CORS，因Echo中间件链与c.Writer封装机制特殊，其他CORS包或手动设Header会绕过关键逻辑，导致OPTIONS预检失败、Access-Control-Allow-Origin被覆盖或带Credentials时header被浏览器丢弃。
必须用 echo/middleware.CORS，其他包会静默失效
直接写 w.Header().Set() 或套用 gin-contrib/cors、gorilla/handlers.CORS 都不行——Echo 的中间件链和 c.Writer 封装机制特殊，外部 CORS 中间件会在响应写入前绕过关键逻辑，导致 OPTIONS 预检不返回 204/200、Access-Control-Allow-Origin 被覆盖、带凭证时 header 被浏览器直接丢弃。
唯一可靠方式是：
-
e.Use(echo/middleware.CORS())（使用默认配置） - 或显式调用
e.Use(middleware.CORSWithConfig(...))
AllowCredentials: true 时 AllowOrigins 不能写 "*"
这是最常踩的坑：一旦开启凭据支持（如 Cookie、HTTP 认证），浏览器会强制拒绝 Access-Control-Allow-Origin: *。后端若硬编码 "*"，前端 fetch 即使配了 credentials: 'include' 也会被拦截，且控制台可能只报“CORS policy blocked”，不提示具体原因。
正确做法是动态匹配 Origin：
- 白名单数组里写具体域名，例如
[]string{"http://localhost:3000", "https://app.example.com"} - 若需子域名通配（如
admin.example.com、api.example.com），得自己校验c.Request().Header.Get("Origin")是否符合规则，再回写对应值 - 不要依赖中间件自动通配 ——
echo/middleware.CORS不支持正则或通配符匹配AllowOrigins
OPTIONS 预检失败？检查中间件注册顺序和短路逻辑
Echo 默认不会为 OPTIONS 请求自动返回 204，尤其在启用路由 method filter 或资源路由时，容易直接抛 405 Method Not Allowed。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
解决方法只有两个关键点：
- 确保
CORS中间件注册在所有其他中间件之前：e.Use(middleware.CORSWithConfig(...))必须放在e.Use(...)链最开头 - 如果仍遇到预检失败，手动加短路逻辑（尤其在自定义中间件中）：
if c.Request().Method == "OPTIONS" { return c.NoContent(http.StatusNoContent) }
注意：返回 http.StatusNoContent (204) 比 200 更规范，避免 CDN 或代理对空响应体做额外处理。
带 Cookie 跨域还失败？别漏了 SameSite 和 Secure 配置
即使 CORS 头全对，Cookie 仍可能被浏览器拒绝发送，原因通常是 SameSite 属性冲突。Go 标准库从 1.16+ 才支持 http.SameSiteNoneMode，低于此版本需手动拼字符串：
- 生产环境（HTTPS）：设
SameSite: http.SameSiteNoneMode+Secure: true - 本地开发（HTTP）：退化为
SameSite: http.SameSiteLaxMode，否则 Chrome 会静默丢弃 Cookie -
Domain字段要带前导点（如".example.com"），否则子域名间无法共享
这个环节和 CORS 中间件本身无关，但它是完整跨域鉴权链的最后一环——漏掉就等于前端发了请求，后端根本收不到 Cookie。
