在开发web后台与前端联调的过程中，遇到了一个问题：
Access to XMLHttpRequest at 'xxx' from origin 'yyy' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the rquested resource.
字面意思就是从Y域中去Http请求X域的后台，但是请求反馈的资源的Http头中没有包含'Access-Control-Allow-Origin'内容，什么意思呢？
CORS的意思是跨域资源共享，当web从一个不属于本身所在的服务器的资源地址（域名、协议、端口）请求资源时，就会发起这样一个跨域HTTP请求，比如你的服务所在域名是‘www.aaa.com/yyy’，这时候你的前端想要从‘www.bbb.com/xxx’请求一个资源，就会触发跨域请求。处于安全原因，浏览器会限制这样的跨域请求，除非响应报文中包含了正确的CORS响应头。
因此我就遇到了这样的浏览器报错，提示我返回的响应报文中没有包含需要的响应头，也就是'Access-Control-Allow-Origin'。
要解决这个问题也很简单，首先保证你的后台能够确实地接收到前端的请求（以防被网关等拦截，而非CORS问题，但如果报出了这样的错误，基本是因为响应头的问题），然后再返回的响应头中加上'Access-Control-Allow-Origin'，那对应的值应该是什么呢？对应的值其实就是请求报文头中的‘Origin’字段的内容。所以，确定你要对接的前端的请求的Origin字段是什么，在响应头中添加进去即可，如下：
Request Headers:
Request URL: http://www.bbb.com/xxx
Request Method: POST
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080
从上面的例子可以看到，在请求头中有一个Origin字段，而在响应头中则加了一个对应的Access-Control-Allow-Origin字段，这样浏览器就不会拦截请求和返回了，从而能够顺利的访问。
本来正常了，但后来前端做了一点变化后，又出现了类似的问题，这次不是Access-Control-Allow-Origin的问题了，但也是类似的，其实跨域请求的控制不只是Origin的问题，还有两个字段也是与此相关的：
Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。
前端的请求头中如果增加了 Access-Control-Request-Method 和 Access-Control-Request-Headers 字段，那么后台返回的响应头也必须包含上面两个字段，要注意method前端没有s，但后台有，为什么？前端一次请求必定只有一种方法，但后台需要允许多种方法，尤其是OPTIONS方法，面对POST之类的可能对服务器数据产生变化的请求，前端会默认先进行一次OPTIONS请求（预检请求），验证通过后才会正式发出GET或者POST请求，所以在后台处理时也需要判断当前的请求方法是什么，面对OPTIONS，就不要返回完整的数据了，只需要告知我接受你就行了。所以真实的协议应该类似：
预检请求：
Request Headers:Request URL: http://www.bbb.com/xxx
Request Method: OPTIONS
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: POST
Referer: http://www.aaa.com/yyy
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080
从上面的例子可以看到，在请求头中有一个Origin字段，而在响应头中则加了一个对应的Access-Control-Allow-Origin字段，这样浏览器就不会拦截请求和返回了，从而能够顺利的访问。
本来正常了，但后来前端做了一点变化后，又出现了类似的问题，这次不是Access-Control-Allow-Origin的问题了，但也是类似的，其实跨域请求的控制不只是Origin的问题，还有两个字段也是与此相关的：
Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。
前端的请求头中如果增加了 Access-Control-Request-Method 和 Access-Control-Request-Headers 字段，那么后台返回的响应头也必须包含上面两个字段，要注意method前端没有s，但后台有，为什么？前端一次请求必定只有一种方法，但后台需要允许多种方法，尤其是OPTIONS方法，面对POST之类的可能对服务器数据产生变化的请求，前端会默认先进行一次OPTIONS请求（预检请求），验证通过后才会正式发出GET或者POST请求，所以在后台处理时也需要判断当前的请求方法是什么，面对OPTIONS，就不要返回完整的数据了，只需要告知我接受你就行了。所以真实的协议应该类似：
>预检请求：
>Request Headers:
>>Request URL: http://www.bbb.com/xxx
Request Method: OPTIONS
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: POST
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Access-Control-Allow-Headers: authorization,content-type
Access-Control-Allow-Methods: POST, GET, OPTIONS
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080实际请求
Request Headers:Request URL: http://www.bbb.com/xxx
Request Method: POST
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080
从上面可以看出来，会经历两次请求，第一次OPTIONS方法的预检请求，咨询是否支持POST方法，第二次才是真实请求，在第一次请求中，包含 Origin、Access-Control-Allow-Headers、Access-Control-Allow-Method 三种跨域请求头，在第二次真实请求中，就只有Origin字段了。所以作为后台，需要进行相应的返回：
- 对于Origin：出于安全考虑，后台最好维护一份白名单，只有白名单中的域名Origin，才出现在Access-Control-Allow-Origin中返回，这样可以有效避免其他恶意网站获取或者修改数据。
- 对于Access-Control-Allow-Headers：由于不确定前端会携带何种内容，可以直接获取前端的相应字段内容，复制到返回的响应头的Access-Control-Allow-Headers字段内容中即可。
- 对于Access-Control-Allow-Method：根据业务场景，后台支持何种方法，就放进去即可，逗号隔开多种方法。
至此，跨域请求就完全配置OK，可以正常访问啦。
参考资料：
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS