Iris跨域配置易失效是因为默认不自动处理OPTIONS预检请求，需显式注册OPTIONS路由并配合Cors中间件；否则预检404导致CORS头不生效。
直接用 Cors 中间件，但必须显式处理 OPTIONS 请求，否则前端发的预检请求会 404 或被拦截。
为什么 Iris 的跨域配置容易失效
Iris 默认不自动响应 OPTIONS 预检请求，哪怕你加了 Access-Control-Allow-Origin 头，浏览器在真正发 POST/PUT 前仍会先发一次 OPTIONS。如果路由没注册对应 OPTIONS 处理器，Iris 就返回 404，CORS 头根本不会生效。
常见现象包括：
- Chrome 控制台报错
Failed to load resource: the server responded with a status of 404 (Not Found)，且请求方法显示为OPTIONS - 前端 fetch 报
TypeError: Failed to fetch，但服务端日志里压根没收到该请求 - 部分接口能通（比如纯
GET），但带 body 的请求失败
正确配置 Cors 中间件 + OPTIONS 路由
中间件只负责写响应头，OPTIONS 必须单独注册路由来“接住”预检请求。推荐做法是统一在根路径或 API 前缀下注册通配 OPTIONS：
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 用
app.Use(Cors)注册中间件，让所有后续请求都带上 CORS 头 - 用
app.Options("*", handler)拦截所有OPTIONS请求，不走后续逻辑，直接返回 204 - 避免在每个
GET/POST路由后手动补OPTIONS，维护成本高且易漏
示例代码片段：
func Cors(ctx iris.Context) {
ctx.Header("Access-Control-Allow-Origin", "*")
ctx.Header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,PATCH,OPTIONS")
ctx.Header("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization")
ctx.Header("Access-Control-Max-Age", "86400")
if ctx.Method() == "OPTIONS" {
ctx.StatusCode(204)
return
}
ctx.Next()
}
func main() {
app := iris.New()
app.Use(Cors)
// 必须加这一行：捕获所有 OPTIONS 请求
app.Options("*", func(ctx iris.Context) {
ctx.StatusCode(204)
})
api := app.Party("/api")
api.Get("/users", getUsers)
api.Post("/users", createUser)
app.Run(iris.Addr(":8080"))
}
生产环境要注意的几个细节
开发时用 "*" 看似方便，但上线后可能触发安全策略或影响认证流程：
-
Access-Control-Allow-Origin设为"*"时，Access-Control-Allow-Credentials不能设为true，否则浏览器拒绝响应；如需带 cookie，得明确指定 Origin 域名 -
Access-Control-Allow-Headers要包含前端实际发送的自定义 header，比如X-Auth-Token，否则预检失败 - Iris 的
Party分组对OPTIONS不自动继承，所以app.Options("*", ...)必须写在最外层，不能只写在api.Party("/api").Options(...)里 - 如果用了反向代理（如 Nginx），注意它可能覆盖或删除响应头，需检查代理配置是否透传
Access-Control-*头
最容易被忽略的是：Iris 的中间件执行顺序和 OPTIONS 路由注册位置——中间件必须在 app.Options 之前调用，否则预检请求压根进不到中间件里，头就写不上。
