Express CORS教程

在前后端分离架构成为Web开发主流的今天，几乎所有刚接触Express搭建后端接口的开发者，都曾在浏览器控制台见过那句熟悉的红色报错：No 'Access-Control-Allow-Origin' header is present on the requested resource. 这就是跨域资源共享（CORS）机制触发的拦截，本质是浏览器的同源策略在起作用，也是后端开发必须掌握的基础配置技能之一。

要理解CORS的作用，首先要明确浏览器同源策略的核心规则：只有当两个URL的协议、域名、端口三者完全一致时，浏览器才会认为它们属于同一个源，否则就是跨域。同源策略是浏览器的核心安全机制，用来防止恶意网站窃取其他网站的用户数据，但也给前后端分离的正常业务调用带来了阻碍——通常前端项目运行在本地开发服务器或独立域名下，后端接口部署在另一台服务器或不同端口下，二者天然跨域，此时就需要CORS机制来合法放行跨域请求。CORS是W3C制定的跨域资源共享标准，服务器通过在HTTP响应头中加入特定的标识字段，让浏览器判断当前跨域请求是否被允许，整个过程浏览器自动完成，开发者只需要在后端正确配置对应的响应头即可。

CORS请求分为简单请求和非简单请求两类，简单请求需要同时满足几个条件：请求方法是GET、HEAD、POST三者之一，请求头不超出Accept、Accept-Language、Content-Language、Content-Type（仅限application/x-www-form-urlencoded、multipart/form-data、text/plain）等几个默认字段，且请求中没有使用自定义的业务头字段。简单请求会直接发送实际请求，服务器返回后浏览器检查响应头判断是否放行。而非简单请求，比如使用PUT、DELETE方法，或者Content-Type为application/json，或者携带了Authorization、X-Requested-With等自定义头的请求，浏览器会先发送一个OPTIONS方法的预检请求，询问服务器是否允许当前跨域请求，只有预检通过后才会发送实际的业务请求，这也是很多开发者遇到的“接口明明存在却报跨域错误”的常见原因——后端没有处理OPTIONS预检请求。

在Express中处理CORS最基础的方式是手写自定义中间件，通过给所有响应设置对应的跨域头字段。最基础的配置是设置Access-Control-Allow-Origin为*，代表允许所有源的跨域请求，这种配置适合纯公开接口的场景，但限制是不能携带Cookie等身份凭证。如果需要允许特定源的访问，还可以通过读取请求头中的Origin字段动态判断，比如维护一个允许的源白名单，只有当请求的Origin在白名单中时，才将Access-Control-Allow-Origin设置为对应的源值，同时可以设置Vary: Origin响应头，告诉浏览器响应内容会根据Origin不同而变化。除了源字段，还需要配置Access-Control-Allow-Methods字段来声明允许的请求方法，比如GET, POST, PUT, DELETE, OPTIONS，配置Access-Control-Allow-Headers来声明允许的自定义请求头，比如Content-Type, Authorization, X-Custom-Token。如果需要支持携带Cookie等凭证，还要设置Access-Control-Allow-Credentials为true，此时要注意Access-Control-Allow-Origin绝对不能设为*，必须是具体的源地址，否则浏览器会直接拦截请求。最后还要单独处理OPTIONS预检请求，当检测到请求方法是OPTIONS时，直接返回204或200状态码，不需要走后续的业务逻辑，避免预检请求被路由规则拦截。

虽然手动写中间件能让我们更清晰理解CORS的原理，但在生产环境中，更推荐使用官方维护的cors第三方包，它封装了所有跨域配置的常用逻辑，还能避免手动配置的各种边界问题。使用前首先通过npm install cors安装依赖，然后在Express中引入后直接通过app.use(cors())即可启用默认配置，默认配置下允许所有源的跨域访问，允许GET、HEAD、PUT、PATCH、POST、DELETE等常用方法，允许的请求头包含常用的业务字段，且默认关闭凭证支持。如果需要自定义配置，可以给cors函数传入一个配置对象，比如origin字段可以配置为单个字符串代表允许单个源，配置为数组代表允许多个源，也可以配置为一个接收请求对象和回调函数的异步函数，动态判断当前请求的Origin是否符合要求，适合从环境变量中读取允许的白名单的场景。methods字段用来配置允许的请求方法，allowedHeaders配置允许的请求头，exposedHeaders配置允许前端读取的响应头，比如自定义的X-Token字段如果没有配置在exposedHeaders里，前端是拿不到的。credentials字段用来开启凭证支持，maxAge字段用来配置预检请求的缓存时间，单位是秒，设置后在缓存时间内同一源的同类非简单请求不需要再发送预检请求，提升请求性能。

除了全局配置，cors包也支持针对单个路由或路由组配置跨域规则，适合大部分接口不需要跨域、只有少数接口需要开放的场景。比如在某个接口的路由处理函数前传入cors中间件，只有这个接口会单独启用跨域配置，其他接口不受影响。如果使用Express的Router管理路由组，也可以在路由实例上调用use方法挂载cors中间件，实现整个路由模块的跨域配置，和全局配置的逻辑完全一致，只是作用范围限定在当前路由组内。

在配置Express CORS的过程中，有几个常见的坑需要特别注意。第一个坑是凭证和全源配置冲突：当Access-Control-Allow-Origin设置为*时，绝对不能开启credentials配置，否则浏览器会直接报跨域错误，这是W3C标准的硬性规定，哪怕业务上不需要限制源，只要需要携带Cookie，就必须动态设置Origin为请求的实际源值。第二个坑是遗漏自定义请求头配置：如果前端请求携带了自定义的头字段，比如业务常用的Authorization token字段，必须在allowedHeaders中明确声明，否则预检请求会失败。第三个坑是没有处理OPTIONS请求：虽然cors包默认会处理OPTIONS请求，但如果手动写中间件或者有其他中间件先拦截了OPTIONS请求，就会导致预检失败，开发时如果遇到非简单请求一直报跨域错误，可以先在浏览器网络面板看OPTIONS请求的状态码和响应头排查问题。

从安全角度出发，生产环境尽量不要配置全局允许所有源的跨域规则，尤其是涉及用户身份验证的接口，全源开放会增加CSRF攻击的风险，应该根据业务需求维护明确的跨域白名单，通过环境变量管理不同环境的白名单列表，开发环境配置本地前端开发服务器的地址，生产环境配置线上前端域名。如果是对接口安全要求较高，还可以配合CSRF Token等安全措施，进一步提升接口安全性。很多开发者在开发阶段喜欢用前端构建工具的反向代理解决跨域，比如Vite的proxy配置、Webpack的devServer proxy，这种方式本质是开发服务器做了一层请求转发，绕过了浏览器的同源策略，只适合开发阶段使用，生产环境部署时还是需要通过CORS或者Nginx反向代理来解决跨域问题。

CORS是Express后端开发中处理跨域的标准解决方案，理解其底层原理能帮助我们快速排查跨域相关的问题，而使用成熟的cors包则能提升开发效率，减少配置出错的概率。不管是手动实现还是使用第三方包，核心都是围绕同源策略的规则和业务的安全需求来配置，在保障前后端正常交互的守住接口的访问安全底线。