关于CORS（跨域资源共享）的技术疑问

问题1：跨域请求时浏览器的拦截逻辑 #

分两种场景：

• 简单请求：浏览器会直接把请求发送到目标服务器（abc.com），服务器处理后返回响应。这时浏览器会检查响应头里的Access-Control-Allow-Origin等CORS相关字段，如果这些字段不允许当前源（www.example.com）的访问，浏览器就会拦截这个响应，不让前端JS拿到结果，但请求本身已经到达服务器并被处理了。
• 非简单请求（比如带自定义头、PUT/DELETE方法）：浏览器会先发送一个OPTIONS预检请求到服务器，询问是否允许当前源的跨域请求。如果服务器返回的响应不允许，浏览器就会直接拦截后续的实际请求；如果允许，才会发送真正的业务请求。

问题2：CORS的责任是否完全在Web服务器？ #

不是。CORS是浏览器和服务器配合实现的同源安全机制：

• 服务器负责配置Access-Control-*系列响应头，明确允许哪些源、方法、头的跨域请求。
• 浏览器负责自动添加Origin请求头、发起预检请求、校验服务器返回的CORS响应头，最终决定是否允许前端JS获取响应结果。
  两者缺一不可，所以不能说责任完全在服务器。

问题3：使用CURL等工具调用API时的CORS问题 #

CORS本质是浏览器专属的同源安全限制，只有在浏览器环境下才会触发。像CURL这类非浏览器工具：

• 不会自动添加Origin请求头（除非你手动指定-H "Origin: xxx"）。
• 也不会对服务器的响应做CORS校验。
  所以默认情况下用CURL调用跨域API，不会遇到浏览器层面的CORS问题。就算服务器有CORS配置，只要你不手动加Origin头，服务器不会触发CORS相关的校验逻辑；如果手动加了Origin头，服务器可能会根据配置返回对应的CORS响应，但工具本身不会因为这个拦截结果。

内容的提问来源于stack exchange，提问作者user3103957