Buffalo默认不处理OPTIONS请求，需显式配置CORS：可用CORSMiddleware全局处理（AllowMethods必须含"OPTIONS"），或用app.Options()为特定路径手动注册；调试时需检查响应头、Origin匹配及中间件注册顺序。
Buffalo默认不处理OPTIONS请求
Buffalo框架在默认中间件链中不会自动响应OPTIONS请求，浏览器发起跨域预检（CORS preflight）时若后端无响应，会直接报net::ERR_FAILED或404 Not Found。这不是Bug，而是设计选择：Buffalo把CORS策略交由开发者显式控制，避免隐式放行带来安全风险。
- 所有未注册的HTTP方法（包括
OPTIONS）都会走到404处理器 - 即使路由存在
GET/POST，也不代表OPTIONS自动可用 - 手动注册
OPTIONS路由前，务必确认是否真需要自定义响应头（比如非标准Access-Control-Allow-Headers）
用Options()方法注册简单OPTIONS路由
最轻量的做法是为特定路径显式添加OPTIONS处理函数，适用于单个接口或少数几个端点需要定制预检响应的场景：
app.Options("/api/users", func(c buffalo.Context) error {
c.Response().Header().Set("Access-Control-Allow-Origin", "*")
c.Response().Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE")
c.Response().Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
return c.Render(200, nil)
})
- 必须放在
app.GET/app.POST等同路径注册之后，否则可能被路由匹配短路 - 返回
c.Render(200, nil)比return nil更稳妥——后者可能触发默认404 - 如果只做CORS，且规则统一，优先考虑中间件方案而非逐个注册
用CORSMiddleware统一处理所有OPTIONS请求
项目需全局支持CORS时，应使用Buffalo内置的CORSMiddleware，它会自动拦截并响应OPTIONS预检请求，无需手动写路由：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
app.Use(middleware.CORSMiddleware(&middleware.CORSConfig{
AllowOrigins: []string{"https://example.com"},
AllowMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
AllowHeaders: []string{"Content-Type", "Authorization"},
ExposeHeaders: []string{"X-Total-Count"},
MaxAge: 300,
}))
-
AllowMethods里必须显式包含"OPTIONS"，否则中间件不会接管预检请求 - 该中间件会自动对所有匹配Origin的
OPTIONS请求返回200 + 对应头，原路由函数完全不执行 - 若同时手动注册了
app.Options(...)，且路径被CORSMiddleware覆盖，则自定义逻辑不会运行
调试OPTIONS请求失败的三个关键检查点
当OPTIONS仍返回404或CORS错误，按顺序排查以下三项：
- 浏览器开发者工具Network面板中，点击
OPTIONS请求 → 查看Response Headers是否含Access-Control-Allow-Origin；若没有，说明中间件未生效或未命中配置的Origin - 检查
AllowOrigins是否匹配实际请求来源（注意"*"不能和AllowCredentials: true共存） - 确认
CORSMiddleware注册位置在app.Use(...)中靠前位置，不能放在app.ANY或自定义中间件之后，否则可能被跳过
复杂的地方往往不在代码怎么写，而在于预检请求的Origin、Credentials、Headers三者是否与中间件配置严格对应——少一个字符都可能让浏览器拒绝后续请求。
