根本原因是alloworigins设为"*"却启用allowcredentials:true，浏览器会静默丢弃响应；必须改用具体域名或alloworiginfunc，并确保预检请求（options）的allowmethods、allowheaders配置完整，且cookie含samesite=none和secure属性。
为什么 Fiber 的 CORS 中间件加了还是报错？
根本原因不是没加中间件，而是 AllowOrigins 设成了 "*" 却又开了 AllowCredentials: true。浏览器在检测到前端请求带 credentials: "include"（比如 Axios 的 withCredentials: true）时，会直接丢弃响应头中 Access-Control-Allow-Origin: "*" 的响应——连错误细节都不给，只在控制台显示模糊的 “CORS error”。
- 必须把
AllowOrigins改成具体协议+域名+端口，例如["http://localhost:5173", "https://myapp.com"] - 如果前端有多个环境（开发/测试/生产），别硬编码，改用
AllowOriginFunc动态校验 origin 字符串 -
AllowCredentials: true和AllowOrigins是绑定关系：只要开了前者，后者就绝不能含通配符
Fiber 中如何为特定路由启用 CORS？
全局加中间件最省事，但有些接口（比如公开的健康检查或文档页）不该带凭证头，有些管理接口又必须严格限制来源。这时候得靠路由级控制。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 用
app.Use("/api", cors.New(...))给所有/api开头的路由加中间件，比app.Use(cors.New(...))更精准 - 如果只有某几个路由要跨域（比如
/login和/profile），直接在注册时链式调用：app.Post("/login", cors.New(...), handler) - 注意中间件顺序：CORS 必须在身份验证、日志等中间件之前，否则预检请求（OPTIONS）可能被拦截或头被覆盖
预检请求（OPTIONS）失败的三个常见配置漏项
浏览器发 OPTIONS 请求后返回 404 或 403，不是路由没定义，而是 CORS 中间件没正确响应预检。关键参数缺一不可：
-
AllowMethods必须显式列出真实请求用到的方法，比如["GET", "POST", "PUT", "DELETE"]；默认值只含["GET", "HEAD", "POST"]，缺 PUT/DELETE 就会 405 -
AllowHeaders要包含前端实际发送的非简单头，比如"Authorization"、"X-Request-ID"、"Content-Type"；漏掉任一个，预检就失败 -
MaxAge建议设为3600（1 小时），避免每次请求都触发 OPTIONS，减少无效往返
Cookie 凭证能传过去，但后端收不到？查 SameSite 和 Secure
即使 Fiber 正确返回了 Access-Control-Allow-Credentials: true，前端也设置了 credentials: "include"，Cookie 还是进不了后端——问题大概率出在 Cookie 自身属性上。
- 服务端 Set-Cookie 时必须带
SameSite=None，否则现代浏览器（Chrome 80+）会拒绝发送 - 一旦设了
SameSite=None，就必须同时带Secure属性（即只走 HTTPS）；开发环境用http://localhost时，可临时设SameSite=Lax或SameSite=Strict避开限制 - Fiber 的
ctx.Cookie方法不自动加这些属性，需手动拼：ctx.Cookie(&fiber.Cookie{HTTPOnly: true, SameSite: "None", Secure: true})
AllowOrigins 和 AllowCredentials 的组合是否合法、预检头是否覆盖全、Cookie 属性是否满足浏览器强制要求——三者缺一，整个链路就断在看不见的地方。
