1. 登录页接口整合完成后，跨域预检先来敲门
跨域预检报错会卡住登录页，根源是 Go 服务端没有响应浏览器先行的 OPTIONS 探针。我先去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建 TaoToken 的 API Key，再把它填给 Codex 当模型通道；Base URL 填 https://taotoken.net/api。跨域策略的 AllowMethods、MaxAge 怎么写，仍由 gin-contrib/cors 结合项目实际决定，TaoToken 只负责统一接入模型请求。
上一轮把后台登录页从占位逻辑切到真实请求后，浏览器控制台开始出现 CORS 提示：从 http://localhost:5173 发起的预检请求没能通过。登录接口的 POST 后端其实能收到，但浏览器在发送 JSON 请求前，会先发一个 OPTIONS 探针询问服务端“允不允许跨域”。这个探针没有拿到 Access-Control-Allow-Origin 响应头，整个登录请求就被浏览器拦下，页面上只留下一段看起来和业务无关的 CORS 报错。
这时工作区里还堆着登录页整合那批改动。我习惯在改另一件事之前把工作区收干净，于是先 git add 新增的 api 文件和 login.vue，再整体 git stash，等跨域配置改完再 git stash pop 接回来。注意新增文件如果不先 add，stash 默认不会把它们一起带走。
1.1 从“接口通了”到“Origin 被拒”，隔了一个 preflight
浏览器跨域规则对预检的条件分得很细。如果是 text/plain 或 form 表单提交，可能不发预检；一旦请求头带着 application/json 或自定义 header，浏览器就会先发 OPTIONS 预检。登录接口提交的是 JSON，所以第一个到达 Go 后端的其实是 OPTIONS /admin/login，不是 POST /admin/login。
Gin 默认路由没有单独注册 OPTIONS 方法，跨域中间件也没挂上，于是预检请求拿不到任何跨域响应头。浏览器的判断是“目标服务不允许跨域”，后续真正的 POST 请求根本不会发出。这就是服务端日志里能看见 OPTIONS、前端却一直提示跨域的原因。想解决，不是在前端加代理绕过，而是让 Go 服务端直接响应预检，并在响应头里给出允许的域名、方法和缓存时间。
gin-contrib/cors 是 Go 项目里 star 数最高的跨域库，直接把官方 GitHub 仓库地址发给 Codex，它会照着最新版 API 来生成，不会给你塞一份过时配置。选择这个库的另一个好处是它把预检缓存、域名白名单、请求头放行都抽象成配置项，正好可以落进 yaml 文件统一管理。
1.2 ~/.codex/config.toml 指到 TaoToken 通道
Codex 默认会读 ~/.codex/config.toml。打开这个文件，把模型供应商指向 TaoToken 的兼容通道。Key 从 TaoToken 控制台创建，Base URL 填 https://taotoken.net/api，末尾不要加 /v1。模型 ID 别靠记忆猜，以模型广场当时列表为准。
# ~/.codex/config.toml model = "YOUR_MODEL_ID" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"然后在终端里把 Key 放进环境变量：
export TAOTOKEN_API_KEY=YOUR_API_KEY配置完成后，在项目目录启动 codex，先让它读跨域报错和项目结构。Codex 只负责生成、解释和对照代码，编译运行这些动作由你在本地完成，它不会连接任何线上环境。现在可以把登录接口整合完成后的跨域报错原样贴给它，同时让它检查项目里有没有已经存在的 cors.yaml。
2. 给 Codex 的第一份材料：报错原文 + 当前 cors.yaml
2.1 把跨域报错和目录现状先贴给 Codex
如果项目里还没有 config/cors.yaml 和 internal/middleware/cors.go，把完整需求发给 Codex：整合 gin-contrib/cors，新建一个配置文件用于配置允许跨域的域名列表，默认允许所有请求头和请求方法，只在域名上做限制，预检请求最大缓存时间 24 小时；在 internal/middleware 下单独建立 cors.go，最后到 api/main.go 里注册。
一条可用的初始提示词是这样的：
现在解决跨域问题：整合 github.com/gin-contrib/cors 跨域库。 新建 config/cors.yaml 配置允许跨域的域名列表；默认允许所有请求头和请求方法，只对域名做限制。 预检请求最大缓存时间设为 24 小时。 在 internal/middleware 下建立 cors.go，使用以上跨域库结合配置文件实现 CORS，并在 api/main.go 注册。Codex 第一版通常会把允许方法写成 GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS 一长串。这不算错，但后续想增加一种方法，就要回头改中间件再发版。gin-contrib/cors 的 AllowMethods 支持 *，让 Codex 直接改成通配，更省事，也更贴合“默认允许所有请求方法”的原始需求。
2.2 从“手动列方法”到 *，review 一次就够了
AllowMethods 用 *，意思是所有 HTTP 方法都放行。很多人会担心这样太危险，但只要想清楚 CORS 的职责边界就不会慌：CORS 解决的是浏览器跨域读取响应的问题，服务端的登录接口仍然要靠 token 和权限中间件把关。跨域放行不等于匿名访问，所以方法层面放开，对开发效率的收益远大于风险。
同样，AllowHeaders 也建议用 *。前端登录请求可能携带 Content-Type、Authorization，如果写死一份列表，以后新增 header 就容易漏。真正需要严格控制的只有 AllowOrigins，因为它是接口面的第一道门，直接决定哪些前端页面能拿到你的响应。
gin-contrib/cors 本身有一个默认行为要当心：不设置 AllowOrigins 时可能会直接允许所有来源。对登录接口来说这绝对不能接受，所以本文的 cors.yaml 里只放入 localhost 和 127.0.0.1，开发环境够用，线上部署时再按实际域名收敛。
3. 预检缓存 24 小时，默认值要写在 config/cors.yaml
3.1 默认值放 yaml，不要变成 Go 代码里的硬编码
处理跨域配置最容易踩的坑，是把默认值硬编码进 Go 代码。Codex 第一次生成时，可能会写出“如果 methods 为空，就默认 GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS；headers 为空就默认 *”的逻辑。表面看是给空配置兜底，实际上会让 config/cors.yaml 失去意义——你清空某个字段后，代码填回一套默认值，配置文件里写的仍然是无效配置。
正确做法是让 yaml 成为唯一事实来源。yaml 里写了什么，就传给 gin-contrib/cors 什么；yaml 里留空，就保持 nil，让库自己决定。不要让中间件额外包一层默认值逻辑。配置文件示例：
# config/cors.yaml allow_origins: - localhost - 127.0.0.1 allow_methods: - "*" allow_headers: - "*" max_age_hours: 24max_age_hours 是 24，对应 86400 秒的预检缓存。同一个浏览器在 24 小时内再次发起同类型跨域请求，不会再重复 OPTIONS 探针，而是直接走正式请求。登录页反复进出的场景下，这个缓存能让每次返回后台都少一次网络往返。
3.2 域名白名单只填域名，端口和协议交给中间件补
如果前端地址是 http://localhost:5173、http://localhost:8080、https://localhost:8081，你可能会在 yaml 里列三行带协议和端口的地址。但这种写法维护成本很高，浏览器 Origin 里的端口一变，配置就要跟着改。更合适的方式是白名单里只写裸域名，在 cors.go 里解析请求的 Origin，取出 Hostname 部分去白名单比对。
import ( "net/url" "time" "github.com/gin-contrib/cors" "github.com/gin-gonic/gin" ) func CORS() gin.HandlerFunc { // cfg 由 config/cors.yaml 解析得到，这里省略读取细节 allowed := make(map[string]struct{}, len(cfg.AllowOrigins)) for _, origin := range cfg.AllowOrigins { allowed[origin] = struct{}{} } return cors.New(cors.Config{ AllowMethods: cfg.AllowMethods, AllowHeaders: cfg.AllowHeaders, MaxAge: time.Duration(cfg.MaxAgeHours) * time.Hour, AllowOriginFunc: func(origin string) bool { u, err := url.Parse(origin) if err != nil { return false } _, ok := allowed[u.Hostname()] return ok }, }) }url.Parse 会把 Origin 拆成 scheme、host、port，u.Hostname() 拿到的就是不带端口的 localhost。这样 localhost:5173 和 localhost:8080 都能命中，同时 http 和 https 两种协议也都覆盖。第一次测试时就是吃了“域名还得加上端口号”的亏，改成 Hostname 比对后一劳永逸。
4. 本地启动实测：curl 打一发 OPTIONS 预检
4.1 观察 Access-Control-Max-Age 是否等于 86400
中间件注册好之后，在本地启动 Go 服务，先用 curl 模拟一次跨域预检，确认响应头没有缺项，再回浏览器刷新登录页。命令如下：
curl -i -X OPTIONS 'http://127.0.0.1:8080/admin/login' \ -H 'Origin: http://localhost:5173' \ -H 'Access-Control-Request-Method: POST' \ -H 'Access-Control-Request-Headers: content-type'关键看响应头里有没有这几项：
Access-Control-Allow-Origin: http://localhost:5173 Access-Control-Allow-Methods: * Access-Control-Allow-Headers: * Access-Control-Max-Age: 86400Max-Age 单位是秒，86400 正好等于 24 小时。如果它出现了，说明预检缓存已经生效。如果 Allow-Origin 缺失，检查白名单里的 hostname 是否和 Origin 解析出来的 Hostname 一致；如果 Allow-Methods 没生效，确认 yaml 里 allow_methods 不是空数组。如果 Codex 在排障过程中提示模型 ID 不可用，先回 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场核对当前列表，把 config.toml 里的 YOUR_MODEL_ID 替换成真实值。
4.2 localhost:5173 和 127.0.0.1 是两个 Origin
第一次测试时，前端和后端都在本机，下意识觉得 localhost 和 127.0.0.1 是一回事。实际浏览器把 Origin 字符串整体当作来源比较，http://localhost:5173 和 http://127.0.0.1:5173 是截然不同的两个 Origin。如果你的前端地址栏是 127.0.0.1，而 cors.yaml 里只写了 localhost，预检照样失败。
这个坑恰好验证了 3.2 用 Hostname 匹配的思路是对的：配置里写 localhost，比对时把端口和协议剥掉，不管前端切到哪个端口都能过。把 curl 的响应头完整贴回给 Codex，它会自己判断是哪一项没有对齐。本地测试通过后，再 git stash pop 把登录页整合的改动恢复出来，连起来跑一遍真实登录流程。
5. 复盘与后续：Codex 改配置，我给结论
5.1 这轮修复里，Codex 承担了什么
Codex 在这次排障里做了三件事：分析 OPTIONS 预检失败的原因；生成 gin-contrib/cors 的整合代码；根据 review 意见把 AllowMethods 改成 *、把默认值搬进 yaml、用 Hostname 匹配域名白名单。它没有直接连接任何生产环境，所有改动都落在本地工作区，最后由我在本地启动验证，再把结果贴回对话继续修正。
跨域配置看起来只有几十行，却直接影响接口面是否暴露给不该访问的页面。白名单写成 * 的风险很高，所以 Codex 的初版生成完，人工 review 反而比生成更关键。我的检查原则是：配置文件是唯一事实来源，代码里不藏着隐式默认值；白名单尽量窄，开发环境只放 localhost 和 127.0.0.1；方法放开没问题，接口鉴权必须留在服务端。登录请求绑定从 form 改成 json、后端字段 tag 从 PascalCase 对到 snake_case，这些其实是在跨域修完、整个登录流程串起来之后才暴露出来的，属于同一个测试周期的产物。
5.2 回到控制台对一下这次调用
排障过程中 Codex 每轮修改都会消耗模型调用，跑通之后可以到 模型对话 用同一把 Key 发一条测试消息，确认调用计费正常；如果接下来要长期让 Codex 或 Claude Code 写项目代码，打开 Coding Plan 看套餐是否够用。Key 统一在 控制台 API Keys 创建，Claude Code 的环境变量写法见 接入文档。
