首先供上我的答案（也可能会打脸）：
会。跨域请求浏览器可以正常发送服务器也可以正常返回响应，只不过响应被浏览器拦截了而已。
揭晓一下答案，请求有的时候会被执行，有的时候不会执行。
那啥时候会执行，啥时候不会执行呢？其实这个问题主要要从以下几个方面去考虑：
- 跨域究竟是谁的策略？浏览器
- 在什么时机会拦截请求？
- 究竟什么时候会发预检请求？非简单请求
- 如果有预检，请求什么时候会被真正执行？预检请求返回允许跨域的相关头部时
跨域请求的拦截
首先我们俗称的跨域，也就是浏览器的同源策略
同源：协议、域名、端口号相同
同站：二级域名一致即可（对协议和端口号没有要求）
所以，跨域请求的拦截是浏览器干的。
如果服务端拦截，那每个 Server 都要专门要为浏览器实现一个拦截策略，这根本不现实。另外，服务端就算是想拦截，也没法判断请求是否跨域，HTTP Reqeust 的所有 Header 都是可以被篡改的，它用什么去判断请求是否跨域呢？很明显服务端心有余而力不足啊！
什么时候拦截
请求一定是先发出去（预检请求/简单请求的跨域请求），在返回来的时候被浏览器拦截了，如果请求是有返回值的，会被浏览器隐藏掉。
预检请求
什么条件下会发送预检请求？
非简单请求：
- 请求方法是除 GET、POST、HEAD 之外的请求方法
- 请求的首部包含除了 Accept（可以接受的媒体类型）、Content-Type（实体主体的媒体类型）、Accept-Language、Content-Language 之外的请求头
- Content-Type 的值是除了 text/plain、application/x-www-form-urlencoded、multipart/form-data 之外的值
- 请求中的任意 XMLHttpRequest 对象注册了任何事件监听器；XMLHttpRequest 对象可以使用 XMLHttpRequest.upload 属性访问。
- 请求中使用了 ReadableStream 对象。
我们发现，在发送非简单请求之前（真正的请求），浏览器会先发送一个 Preflight 请求，也就是我们常说的预检请求，它的方法为 OPTIONS。
这也就是为什么有的时候我们明明只发了一个请求，在 Network 里却看到两个。
预检请求有一个很重要的作用就是 - 询问服务端是不是允许这次请求，如果当前请求是个跨域的请求，你可以理解为：询问服务端是不是允许请求在当前域下跨域发送。
当然，它还有其他的作用，比如 询问 服务端支持哪些 HTTP 方法。
预检的过程
当预检请求到达服务端时，服务端是不会真正执行这个请求的逻辑的，只会在这个请求上返回一些 HTTP Header，没有响应体。以此来告诉客户端是不是要发送真正的请求。
如果服务端告诉客户端，请求是允许被发送的，那真正的请求才会发出去。这时服务端才会真正执行请求接口的逻辑。
所以，如果你发送的是一个简单请求，这个请求不管是不是会受到跨域的限制，只要发出去了，一定会在服务端被执行，浏览器只是隐藏了返回值而已。
总结
- 简单请求：不管是否跨域，只要发出去了，一定会到达服务端并被执行，浏览器只会隐藏返回值（拦截响应）
- 复杂请求：先发预检，预检不会真正执行业务逻辑，预检通过后才会发送真正请求并在服务端被执行
