Flask CORS教程

在前后端分离的Web开发架构逐渐成为主流的今天，前端应用与后端接口往往部署在不同的域名、端口甚至服务器上，此时浏览器的同源策略就会成为前后端数据交互的第一道障碍，而跨域资源共享（CORS）机制正是解决这一问题的核心方案，对于使用Python Flask框架搭建后端服务的开发者来说，掌握正确配置CORS的方法是保证前后端顺畅通信的必备技能。

同源策略是浏览器最核心的安全功能之一，它要求两个URL的协议、域名、端口三者完全一致，才允许进行资源交互，否则浏览器就会阻止跨域的请求响应，以此防止恶意网站窃取用户的敏感数据。但在实际的开发场景中，我们常常会遇到前端运行在`http://localhost:3000`（比如React、Vue开发服务器），而后端Flask服务运行在`http://localhost:5000`的情况，这时候两个地址的端口不一致，就会触发跨域限制，前端发起的请求会被浏览器拦截，控制台出现类似“Access to XMLHttpRequest at 'http://localhost:5000/api/data' from origin 'http://localhost:3000' has been blocked by CORS policy”的报错信息，这时候就需要我们在Flask后端配置CORS来允许跨域请求。

在Flask中配置CORS最常用也最便捷的方式是使用`flask-cors`扩展包，它可以帮助我们快速为整个应用或者特定的路由添加CORS支持，无需手动编写响应头逻辑。首先我们需要先安装这个扩展包，打开终端执行`pip install flask-cors`命令即可完成安装，这个包会自动适配当前安装的Flask版本，兼容性非常好。安装完成后，最简单的使用方式就是直接导入CORS类并对整个Flask应用进行初始化，比如在你的app.py文件中，先从flask导入Flask，再从flask_cors导入CORS，然后创建app实例后调用`CORS(app)`，这样就能允许所有来源的跨域请求访问所有的接口路由，这种方式非常适合在开发阶段使用，能够快速验证前后端的连通性，不用纠结跨域配置的问题。

不过在生产环境中，我们肯定不能允许所有来源的请求都能访问我们的后端接口，这样会带来很大的安全风险，这时候就需要对CORS的参数进行精细化配置。`flask-cors`提供了非常丰富的配置参数，我们可以通过`resources`参数指定哪些接口路径需要开启CORS，通过`origins`参数指定允许哪些来源的请求，通过`methods`参数指定允许的HTTP请求方法，通过`allow_headers`参数指定允许的请求头，还有`supports_credentials`参数用来指定是否允许携带身份凭证（比如Cookie、Authorization头）。比如我们想要只允许来自`https://www.example.com`的请求访问`/api/`开头的接口，并且允许携带Cookie，就可以这样配置：`CORS(app, resources={r"/api/*": {"origins": "https://www.example.com", "supports_credentials": True}})`，这样配置之后，只有指定域名的请求才能访问我们的api接口，其他来源的请求依然会被同源策略拦截，大大提升了服务的安全性。

除了对整个应用进行全局配置之外，`flask-cors`还支持对单个路由进行CORS配置，使用`@cross_origin`装饰器就可以实现，这种方式非常灵活，适合那些只有少数接口需要跨域的场景。比如我们有一个获取用户信息的接口`/api/user`，只需要给这个接口加上`@cross_origin(origins="https://www.example.com")`装饰器，那么只有这个接口支持跨域访问，其他接口依然保持默认的同源限制。这种按需配置的方式可以最大程度地减少安全暴露面，同时也能满足一些特殊接口的跨域需求，比如有些第三方回调接口可能需要允许特定的外部域名访问，这时候用单个路由的装饰器配置就非常合适。

很多开发者在配置CORS的时候还会遇到预检请求的问题，这也是跨域请求中最容易踩坑的地方。浏览器对于复杂请求（比如请求方法是PUT、DELETE，或者Content-Type是application/json，或者自定义了请求头）会先发送一个OPTIONS方法的预检请求，询问服务器是否允许实际的请求，只有服务器正确响应了预检请求，浏览器才会发送真正的请求。如果Flask后端没有处理OPTIONS请求，或者没有在预检请求的响应头中返回正确的CORS信息，就会导致跨域失败。使用`flask-cors`扩展的话，它会自动帮我们处理所有的OPTIONS预检请求，不需要我们额外编写路由，这也是为什么推荐大家使用扩展包而不是手动添加响应头的重要原因之一。如果是手动配置CORS的话，我们就需要给每个可能触发预检的接口添加OPTIONS方法的处理，并且在响应中添加对应的CORS头，非常繁琐。

当然，我们也可以不使用第三方扩展，手动通过Flask的请求钩子来添加CORS响应头，比如使用`@app.after_request`装饰器，在每个响应返回之前添加`Access-Control-Allow-Origin`、`Access-Control-Allow-Methods`等响应头。这种方式虽然可以实现CORS配置，但需要自己处理各种边界情况，比如预检请求的响应、不同路由的不同配置、凭证携带的逻辑等等，非常容易出错，所以除非是对CORS机制非常了解并且有特殊的定制需求，否则还是建议大家使用成熟的`flask-cors`扩展，既省心又不容易出问题。

在实际的项目部署中，我们还需要注意环境差异带来的CORS问题，比如开发环境我们可以设置允许所有来源，但是生产环境一定要严格限制允许的origin列表，最好将允许的域名配置在环境变量或者配置文件中，根据不同的运行环境加载不同的配置。如果