跨域问题解决:前端调用后端 API 的 CORS 配置方案
🌐 AI 智能中英翻译服务(WebUI + API)中的跨域挑战
在现代前后端分离架构下,前端应用通常运行于独立域名或端口(如 http://localhost:3000),而后端 AI 翻译服务则部署在另一地址(如 http://localhost:5000)。当用户通过双栏 WebUI 发起翻译请求时,浏览器会自动触发跨源资源共享(CORS)安全机制,阻止非法来源访问后端 API 接口。
以本项目为例:
- 前端界面由 Flask 提供静态资源,运行在
/ui路径下 - 翻译 API 接口暴露为
/api/translate - 若未正确配置 CORS 策略,前端 JavaScript 将无法成功调用翻译接口,导致'No 'Access-Control-Allow-Origin' header is present'错误
因此,要实现流畅的中英翻译体验,必须科学配置 CORS 规则,在保障安全性的同时允许合法跨域请求。
🔍 CORS 机制核心原理与常见误区
什么是 CORS?
CORS(Cross-Origin Resource Sharing) 是浏览器实施的一种安全策略,用于限制一个源(origin)的网页能否获取另一个源的资源。只有当服务器明确允许时,跨域请求才能被放行。
💡 判断是否跨域的三要素:
- 协议不同(
httpvshttps)- 域名不同(
localhostvs127.0.0.1)- 端口不同(
:3000vs:5000)
只要其中任意一项不同,即构成跨域请求。
预检请求(Preflight Request)机制
对于非简单请求(如携带自定义 Header、使用 PUT/DELETE 方法等),浏览器会在正式请求前发送一次 OPTIONS 请求,询问服务器是否允许该跨域操作。
OPTIONS /api/translate HTTP/1.1
Origin: http://localhost:3000
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, x-api-key
服务器需响应如下头信息:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: content-type, x-api-key
Access-Control-Max-Age: 86400
否则,实际请求将被拦截。
❌ 常见错误实践
| 错误做法 | 后果 |
|---|---|
返回 * 允许所有源 | 存在安全风险,不支持带凭据请求(withCredentials) |
| 忽略 OPTIONS 请求处理 | 预检失败,POST/PUT 请求无法发出 |
仅设置 Access-Control-Allow-Origin | 缺少方法和 Header 白名单,仍会被拦截 |

