Iris框架中CORS中间件必须手动注册且显式处理OPTIONS预检：需在路由前调用app.Use(Cors)，中间件内须检测ctx.Method()=="OPTIONS"并返回204状态码；Access-Control-Allow-Origin设为"*"时Access-Control-Allow-Credentials必须为false，若需凭证则须白名单校验Origin。
iris 框架中 Cors 中间件必须手动注册才能生效
iris 不像 Laravel 或 FastAPI 那样自动注入 CORS 支持，Cors 中间件只是个函数，不调用 app.Use(Cors) 就完全不会起作用。常见错误是写了中间件函数但忘了在 main() 里注册，结果前端依然报 Access to XMLHttpRequest has been blocked by CORS policy。
注册位置必须在路由定义之前，且建议放在其他中间件（如 recover）之后、业务逻辑之前：
-
app.Use(recover.New())—— 先捕获 panic -
app.Use(Cors)—— 再处理跨域 -
app.Get("/api/data", handler)—— 最后挂路由
OPTIONS 预检请求必须显式响应 204 状态码
浏览器对非简单请求（如带 Authorization 头、Content-Type: application/json）会先发 OPTIONS 请求探路。iris 默认不处理 OPTIONS，如果中间件没拦截并返回 204，就会 404 或 405，导致预检失败。
关键点在于中间件里要主动判断并终止流程：
- 用
ctx.Method() == "OPTIONS"检测预检 - 必须调用
ctx.StatusCode(204)，不能只设 header - 必须加
return，否则继续执行ctx.Next()会走到后续路由，可能 404
示例片段：
if ctx.Method() == "OPTIONS" {
ctx.Header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,PATCH,OPTIONS")
ctx.Header("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization")
ctx.StatusCode(204)
return
}allow-credentials 和 allow-origin 不能同时为 *
当需要前端携带 Cookie 或 Authorization（即 withCredentials: true），服务端必须设置 supports_credentials => true（iris 中对应 Access-Control-Allow-Credentials: true），此时 Access-Control-Allow-Origin **绝不能是 "*"**，否则浏览器直接拒绝响应。
正确做法是动态读取请求头 Origin 并白名单校验：
- 从
ctx.Request().Header.Get("Origin")获取来源 - 只对
http://localhost:3000、https://your-app.com这类明确域名返回该值 - 其他来源可返回空或跳过 header，避免暴露内部策略
硬编码 "*" 看似省事，但只要前端开了 credentials，整个跨域就失效。
生产环境必须限制 allowed_origins，不能长期用通配符
开发时写 ctx.Header("Access-Control-Allow-Origin", "*") 能快速验证流程，但上线后等于开放所有站点读取你的 API 响应——攻击者可诱导用户访问恶意页面，然后用 JS 发起跨域请求窃取敏感数据（比如用户 token、个人信息）。
真实部署应严格控制来源：
- 禁用
"*"，改用白名单数组匹配Origin - 避免正则过度宽松（如
^https?://.*\.example\.com$可能误放子域名） - 若需多环境支持（dev/staging/prod），建议通过配置文件或环境变量注入域名列表，而非硬编码
最易被忽略的是：很多人以为“只配了后端就完事”，却忘了 Nginx/Apache 层可能覆盖或缺失 CORS header，尤其当 iris 前面套了反向代理时，header 可能被清空或重复 —— 这种情况必须检查代理配置是否透传 header。
