Go HTTP Server默认不支持跨域，需手动配置中间件处理OPTIONS预检请求并设置Access-Control-Allow-Origin等响应头，否则浏览器拦截请求；生产环境禁用*通配符（尤其启用凭证时），推荐使用gin-contrib/cors等成熟中间件。
Go HTTP Server 默认不支持跨域，必须手动配置中间件
浏览器发起的跨域请求（比如前端调用 localhost:3000 的 JS 请求后端 localhost:8080）会被直接拦截，不是后端没收到，是根本没发出去——这是浏览器同源策略的预检（preflight）机制在起作用。Go 的 net/http 包默认对 OPTIONS 请求无响应，也不设置 Access-Control-Allow-Origin 等头，所以必须自己加逻辑。
常见错误现象：Failed to fetch + 控制台报 No 'Access-Control-Allow-Origin' header；或者预检请求返回 404/405（因为没处理 OPTIONS）。
- 最简方案：在 handler 前加一层中间件，统一写入 CORS 头，但要注意：只对非
OPTIONS请求设Access-Control-Allow-Origin，而OPTIONS请求必须返回 200 并带上所有允许头 - 别直接在每个 handler 里重复写
w.Header().Set(...)，容易漏、难维护 - 生产环境慎用
*值——当请求带Credentials（如 cookie）时，Access-Control-Allow-Origin不能为*，必须指定明确域名 - 如果用了 Gin/Echo 等框架，优先用官方维护的 CORS 中间件（如
gin-contrib/cors），它们已处理了预检、缓存、凭证等边界情况
用 gorilla/handlers.CORS 时，AllowCredentials 和 AllowedOrigins 必须配套设置
gorilla/handlers 是 Go 生态最常用的通用中间件包，它的 CORS() 函数看似简单，但两个关键参数一旦不匹配，就会导致 401 或静默失败。
典型错误：开了 AllowCredentials: true，但 AllowedOrigins 还写成 ["*"]，结果浏览器报错 The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'。
立即学习“go语言免费学习笔记（深入）”；
-
AllowedOrigins必须是具体域名列表，例如[]string{"https://example.com", "http://localhost:3000"}，不能含路径或通配符子域名（https://*.example.com不被支持） - 如果需要动态 Origin（比如多租户 SaaS 前端域名不固定），得自己写中间件解析
Origin请求头并白名单校验，gorilla/handlers.CORS不支持回调函数式匹配 -
ExposedHeaders要显式列出前端 JS 需要读取的响应头（如X-Total-Count），否则response.headers.get("X-Total-Count")返回 null - 注意
MaxAge单位是秒，设太大可能让前端误用过期的预检缓存
使用 Gin 框架时，gin-contrib/cors 的 Config 结构体字段名易混淆
Gin 用户常直接复制文档示例，但 AllowOrigins 和 AllowOriginsFunc 二选一即可，同时设会覆盖前者；更隐蔽的是 AllowHeaders 和 ExposeHeaders 完全不同：前者告诉浏览器“哪些请求头允许发”，后者告诉浏览器“哪些响应头允许 JS 读”。
错误现场：前端发了 Authorization 头，但服务端 AllowHeaders 没包含它，预检就失败；或者后端返回了 X-Rate-Limit，但没写进 ExposeHeaders，前端拿不到。
-
AllowHeaders默认值是["Content-Type", "Authorization"]，但如果前端还发了X-Request-ID，就得显式追加 -
AllowAllOrigins: true等价于AllowOrigins: []string{"*"}，但同样不兼容AllowCredentials: true -
AllowMethods默认是["GET", "POST", "PUT", "PATCH", "DELETE", "HEAD"]，如果用了自定义方法（如REPORT），必须手动加 - 别把
Config传给cors.New()后直接Use()，要确保它在路由注册前注册，否则静态文件等路由可能绕过
调试 CORS 问题时，先看 Network 面板里的 OPTIONS 请求响应头
很多开发者卡在“前端报错但后端日志没记录”，其实是因为浏览器在发正式请求前，悄悄发了一次 OPTIONS 预检——这个请求如果被路由忽略、被中间件拦截、或 handler panic，就不会进业务日志，但浏览器已判定跨域失败。
正确排查路径：打开 Chrome DevTools → Network → 找到那个 OPTIONS 请求 → 点开 → 查看 Response Headers 是否包含 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等；再看 Status 是否为 200（不是 204 或 304）。
- 如果 OPTIONS 返回 404：检查路由是否注册了该路径的 OPTIONS 方法，或中间件是否提前 return
- 如果 OPTIONS 返回 200 但缺关键头：确认中间件确实执行到了
WriteHeader和Header().Set，Gin 中尤其注意是否用了c.Abort()提前退出 - 用
curl -v -X OPTIONS http://localhost:8080/api/users可绕过浏览器，直接验证服务端行为 - 线上环境注意反向代理（Nginx/Caddy）可能覆盖或删除 CORS 头，需检查 proxy_pass 后是否保留 header
真正麻烦的从来不是加几行 CORS 配置，而是预检请求被静默吞掉、凭证模式和通配符冲突、或者代理层二次过滤——这些地方不打日志、不看网络面板，光盯 Go 代码永远找不到根因。
