我喜欢你>_<

一句话摘要#

Apifox 能通不代表浏览器能通；跨域问题的第一检查点应该是预检请求 OPTIONS，不是业务接口参数。

目录#

• 一句话摘要
• 目录
• 问题现场
  • 本章小结
• 关键认知
  • 本章小结
• 方案取舍
  • 本章小结
  • 本章小结
• 总结

问题现场#

我最开始被“Apifox 已经测通”误导了，默认认为后端接口没问题。
但浏览器联调时登录请求始终失败，进一步看 Network 才发现真实请求前的 OPTIONS 预检直接返回了 405 Method Not Allowed。

关键认知#

1. CORS 预检是浏览器行为，不是后端业务逻辑本身：浏览器在非简单请求前会发 OPTIONS 探路，后端必须返回正确的 Access-Control-Allow-* 响应头。
2. Apifox 不受同源策略约束：它发的是裸 HTTP 请求，因此无法覆盖浏览器端的 CORS 问题。
3. 排查顺序要前移到 Network：先看有无 OPTIONS、状态码和响应头，再看业务参数。

方案取舍#

我评估了两条路径：

• 方案 A：后端加 CORS（治根）
  优点是长期干净；缺点是依赖后端团队排期。
• 方案 B：前端走 BFF 代理（快速落地）
  浏览器请求同源 /api/*，由 Next.js 服务端转发到真实后端，能立即绕开 CORS 阻塞。

这次我采用 BFF，因为当前阶段单人推进前端，跨团队沟通成本高，先保证业务联调闭环更务实。

总结#

这次最大的收获不是修了一个 bug，而是校准了排障方法论：
先看浏览器链路，再看业务逻辑；先保证可交付，再逐步推进根治方案。后续项目里，我会默认把 CORS 预检检查纳入联调首步。