Revel需手写CORS中间件，因无内置支持且第三方库不兼容；须在init()中BEFORE阶段注册，校验Origin白名单并分别处理普通请求与OPTIONS预检，禁用通配符以支持凭证。
Revel 框架本身不内置 CORS 中间件，必须手动注入响应头或借助第三方库；直接写死 Access-Control-Allow-Origin: * 在生产环境会破坏带凭证（如 Cookie、Authorization）的请求，且无法满足多端（Web/H5/小程序）差异化 Origin 白名单需求。
Revel 的 HTTP 中间件链里加 CORS 响应头
Revel 的中间件执行顺序固定，app.Init() 之后、路由匹配之前是插入自定义中间件的最佳位置。不能只在 controller 里用 c.Response.Out.Header().Set()，因为预检请求（OPTIONS）根本不会走到 controller 层——它会被框架在路由前拦截并返回 404 或 405。
- 在
app/init.go的init()函数中，在revel.InterceptMethod(..., revel.BEFORE)之后添加自定义中间件 - 中间件需同时处理两类请求：普通请求（补全
Access-Control-Allow-Origin等头）和 OPTIONS 预检请求（直接返回 204 并设置全部预检相关头） - Origin 必须显式校验，不能无条件返回
*；若需支持凭证，Access-Control-Allow-Origin必须回传请求中的Origin值，且不能为通配符 - 示例关键逻辑：
func CorsFilter(c *revel.Controller) revel.Result { origin := c.Request.Header.Get("Origin") if origin == "" { return nil // 非跨域请求，跳过 } allowedOrigins := []string{"https://web.example.com", "https://h5.example.com", "https://miniprogram.example.com"} var match bool for _, o := range allowedOrigins { if o == origin { match = true break } } if !match { return nil // 不在白名单，不加头也不放行 } c.Response.Out.Header().Set("Access-Control-Allow-Origin", origin) c.Response.Out.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS") c.Response.Out.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Requested-With") c.Response.Out.Header().Set("Access-Control-Allow-Credentials", "true") c.Response.Out.Header().Set("Access-Control-Expose-Headers", "X-Total-Count") if c.Request.Method == "OPTIONS" { return revel.EmptyResult{Status: 204} } return nil }
为什么 Revel 不能像 Gin/Express 那样用现成 CORS 库
Revel 的中间件模型是函数式 + 全局注册，不支持类似 cors.New() 这种带配置对象的构造器模式；社区也没有维护活跃、适配 Revel 2.x 的 CORS 包。强行引入 github.com/rs/cors 会因类型不兼容（它期望 http.Handler）而编译失败——Revel 的 *revel.Controller 不是标准 http.Handler。
- 所有第三方 Go CORS 库（如
rs/cors、gin-contrib/cors）都基于net/http标准库封装，而 Revel 自建了请求生命周期管理 - 试图用
http.HandlerFunc包裹再转成 Revel 中间件，会导致c.Params、c.Render等上下文丢失 - 唯一可行路径是手写中间件，控制粒度反而更高：可对接配置中心动态加载白名单，或按 path 前缀分组策略（如
/api/webvs/api/miniprogram）
多端 Origin 白名单怎么动态管理
硬编码在代码里的白名单无法应对测试/预发/生产多环境切换，也难以支撑 H5 和小程序使用不同域名的场景。建议把白名单抽到配置文件，用 Revel 的 revel.Config.StringDefault() 加载。
- 在
conf/app.conf中添加：cors.allowed.origins.web = ["https://web.example.com", "https://staging-web.example.com"] cors.allowed.origins.h5 = ["https://h5.example.com", "https://test-h5.example.com"] cors.allowed.origins.miniprogram = ["https://miniprogram.example.com"]
- 中间件中根据请求路径或 UA 字段判断端类型，再查对应白名单数组，避免一个接口被所有端共享同一套 Origin 规则
- 特别注意微信小程序：其 WebView 内置浏览器的
Origin可能为空或为https://servicewechat.com，此时需改用Referer或自定义 header（如X-Client-Type: miniprogram）做识别依据
最易被忽略的一点：Revel 默认对 OPTIONS 请求返回 405 Method Not Allowed，而不是由你控制的 204。这意味着即使你在中间件里写了 if OPTIONS { return 204 }，也可能根本走不到那行——因为框架在路由匹配阶段就拦下了。务必确认你的路由表里没有显式定义 OPTIONS /xxx，且中间件注册顺序在 revel.BEFORE 阶段足够靠前。
