最稳妥方式是使用官方 fiber/cors 中间件，它正确处理 OPTIONS 预检、凭据传递及头暴露；手动 Set 响应头易漏预检响应、白名单校验、Credentials 冲突等关键逻辑。
直接在 Fiber 中启用 CORS，最稳妥的方式是用官方推荐的 fiber/cors 中间件——它不是第三方拼凑包，而是 Fiber 官方维护的扩展，能正确处理预检（OPTIONS）请求、凭据传递、头字段暴露等细节，避免手写中间件时漏掉关键逻辑。
为什么不能只靠 w.Header().Set() 手动加头？
手动设置响应头看似简单，但会踩几个硬坑：
- 对
OPTIONS预检请求不做特殊处理，浏览器收不到 200 响应，后续请求直接被拦截 - 没检查请求来源是否在白名单内，
Access-Control-Allow-Origin设成*后又带Credentials，浏览器直接报错“Origin * is not allowed with credentials” - 没设置
Access-Control-Allow-Headers或Access-Control-Expose-Headers，前端拿不到自定义响应头（比如X-Request-ID） - 没控制
Access-Control-Max-Age，每次跨域请求前都发一次 OPTIONS，拖慢接口响应
fiber/cors 中间件怎么配才安全又灵活？
安装后导入即可使用，重点在配置项取舍：
- 生产环境必须把
AllowOrigins设为具体域名数组，比如[]string{"https://app.example.com", "https://admin.example.com"}，禁用"*" - 需要前端传 Cookie 或 Bearer Token 时，设
AllowCredentials: true，同时确保AllowOrigins不含通配符 - 如果 API 要支持
PUT、PATCH或自定义 Header（如X-Api-Version），得显式声明AllowMethods和AllowHeaders - 预检结果缓存建议设为
MaxAge: 86400（24 小时），减少重复 OPTIONS 请求
示例代码：
import (
"github.com/gofiber/fiber/v2"
"github.com/gofiber/fiber/v2/middleware/cors"
)
<p>func main() {
app := fiber.New()
app.Use(cors.New(cors.Config{
AllowOrigins: "<a href="https://www.php.cn/link/2eca337b20ca8d8a80df64d82747d7fb">https://www.php.cn/link/2eca337b20ca8d8a80df64d82747d7fb</a>",
AllowCredentials: true,
AllowMethods: "GET,POST,PUT,DELETE,OPTIONS",
AllowHeaders: "Content-Type,Authorization,X-Api-Key",
MaxAge: 86400,
}))
app.Get("/api/data", func(c *fiber.Ctx) error {
return c.JSON(fiber.Map{"data": "ok"})
})
app.Listen(":3000")
}调试时怎么看 CORS 是否真生效？
别只信前端控制台没报错——得看网络面板里实际响应头：
- 发起一个跨域请求（比如从
http://localhost:5173访问http://localhost:3000/api/data） - 在 Chrome DevTools 的 Network 标签页里点开该请求，切换到 Headers → Response 部分
- 确认存在且值正确：
Access-Control-Allow-Origin、Access-Control-Allow-Credentials、Access-Control-Allow-Methods - 如果是非简单请求（比如带
Authorization头的 POST），还要检查 OPTIONS 请求是否返回 200，并带全上述头
最容易被忽略的是：本地开发时前端和后端同域（比如都跑在 localhost:3000），CORS 根本不触发；一部署到真实域名就崩——所以测试务必用真实跨域场景，而不是只看本地跑通了没。
