必须使用echo/middleware.corswithconfig且置于中间件链最前；allowcredentials为true时alloworigins不可用"*"，需明确列出源；allowmethods必须包含echo.options，allowheaders须覆盖前端所有自定义请求头。
必须用 echo/middleware.CORSWithConfig，其他方式会静默失效
直接写 w.Header().Set("Access-Control-Allow-Origin", "*") 或套用 gorilla/handlers.CORS、gin-contrib/cors 都不行。Echo 的中间件链和 c.Writer 封装机制特殊，非官方 CORS 中间件会在响应写入前绕过关键逻辑，导致 OPTIONS 预检返回空白或 404，浏览器控制台里看不到错误，只看到“failed to fetch”。
根本原因是：Echo 的 Context 对 response 的封装是惰性的，c.NoContent()、c.String() 等方法一旦调用，就触发底层 http.ResponseWriter.WriteHeader()；之后再设 header 全部被忽略。而其他框架的 CORS 中间件没感知这个时机，header 设置晚了。
正确做法只有一条：e.Use(middleware.CORSWithConfig(...)) 必须放在 e.Use() 链最前面（或至少在所有可能提前写响应的中间件之前）。
AllowCredentials: true 时 AllowOrigins 不能用 "*"
这是浏览器强制限制：带凭证（Cookie / Authorization）的跨域请求，Access-Control-Allow-Origin 值不能是通配符 "*"，否则响应会被直接丢弃，Network 面板里连 status 都看不到。
常见错误配置：
-
AllowOrigins: []string{"*"}+AllowCredentials: true→ 浏览器静默拦截 -
AllowOrigins: []string{"http://localhost:3000"}+AllowCredentials: true→ 正确，但前端 fetch 必须带credentials: 'include' -
AllowOrigins: []string{"https://myapp.com", "http://localhost:3000"}→ 白名单要列全，漏一个就预检 403
如果需要动态 origin（比如多租户），得自己写中间件提取 c.Request().Header.Get("Origin") 后白名单校验，再调用 c.Response().Header().Set("Access-Control-Allow-Origin", origin) —— 但这手动方式极易出错，不推荐，优先收口到 CORSWithConfig 的 AllowOrigins 列表里。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
OPTIONS 返回 404 或空响应？检查中间件顺序和 AllowMethods
OPTIONS 请求不是路由问题，而是中间件链被“短路”了。典型现象：你没写 router.OPTIONS("/api/user", ...)，但本该由 CORS 中间件自动处理，结果却 404。
原因有二：
-
AllowMethods没显式包含echo.OPTIONS—— Echo 不会自动补全，漏了它，CORS 中间件就认为该路径不支持预检，直接跳过 - 前面的中间件（如 auth、logging）已调用了
c.String()或c.JSON()，导致响应头无法再设置；尤其注意自定义 auth 中间件里写了c.JSON(401, ...)却没return，流程继续往下走，CORS 尝试设 header 但状态码已发，失败
验证方法：把 e.Use(middleware.CORSWithConfig(...)) 移到 e.Use() 第一行，注释掉其他中间件，再测 OPTIONS。能通了，就说明是顺序或前置中间件干扰。
调试时别只看 Network 面板的响应体，重点看响应头和状态码
当跨域失败，很多人盯着 Response Body 看是不是空，其实关键在 Headers 标签页：
- 有没有
Access-Control-Allow-Origin？值是否匹配前端 origin？ - 有没有
Access-Control-Allow-Credentials: true？（如果前端发了 credentials） - 预检请求（OPTIONS）的 status 是 204 还是 200？Echo 默认返回 204，不是错误
- 如果看到
Access-Control-Allow-Origin: null，说明后端代码里用了c.Request().Header.Get("Origin")但没做空判断，返回了空字符串
最容易被忽略的是：CORS 配置里的 AllowHeaders 必须列全前端实际发送的自定义头，比如 X-Request-ID、X-Auth-Token，漏一项，预检就 403，且浏览器不提示具体哪个头不合法。
