<img />标签请求图片资源浏览器自动在请求头中加Authorization问题
事情的由来
在这个安静宁和的系统中，有一天突然啪的一下图片显示异常了。本来之前可以显示的图片突然就离家出走不显示了。
查找问题
摸了摸头开始企图在代码中找出一丝蛛丝马迹，但是翻烂了代码也没有找出个所以然。。。代码看似一切正常，打印出来的图片路径也没什么问题。嗯...（沉思ing）
图片src的值是后端返回的一个图片名称（带后缀），然后再进行拼接Token和时间戳得到的
直接把图片链接放到apifox中获取也没有问题：
为什么在浏览器中就出现问题？饿...
既然如此，那我就去求助外援了！然后就去找后端同学了。
与后端同学查找ing
后端同学：我勒个骚刚！你这token从哪偷来的？验证没通过。
我：这token不就从你这获取的吗？url请求参数的那个，你不是取的是这个吗？
后端同学：我说的是请求头里面的Authorization标头的token值，我写的逻辑中如果请求头中Authorization标头有值就不会再去取URL查询参数了。
我：啊？let me see see，卧槽还真有，不是，我没往这加过这标头啊，这TM从哪冒出来的？
于是陷入了沉思...（认真思考中）
这既然是图片展示那么就跟<img />标签有关，就是你了，出来吧！！！
解决方案（临时）
于是我就开始在强大的MDN前端宝典的知识海洋中开始遨游~
疯狂在键盘上弹奏美妙的乐章，在MDN搜索框中敲出一段闪亮的内容：
循着这个路线往下嗅探，最终在MDN文档中找到了蛛丝马迹，就是它<img /> 标签的crossorigin属性：
以迅雷不及掩耳之势打开VSCode，给<img />标签添加了这个属性crossorigin并将这个属性的值设置为anonymous之后，结果显而易见。破费特！成功显示涩图：
以为这样就结束了？嘿嘿，我也~但事情往往没有想象中的那么简单~困难总会接踵而至~
美好的事情又发生啦~
第二个宁静祥和的下午，又来迎接美好的事物啦~宝贝，这次又会是什么令人兴奋的惊喜呢？答案就是：websocket接收不到消息啦~，猜猜是为什么呢？没错又是这个DM，就是它，它又又出现啦！！！
又花了一天时间去查找这个问题，这次绝不放过这小子，势必找到问题的根源将其连根拔起！！
省略查找过程，直接进入主题，经过一番查找终于发现了问题的根本原因。
原因
因为同事给swagger接口文档添加了登录操作，所以swagger需要登录后才能够访问内容。而这个登录操作呢，是通过HTTP Basic Authorization （基本认证）实现的。
简单来说呢就是：
-
我打开swagger文档（页面）的时候，其实就是访问服务端的HTML文档，向服务端
发送了请求。 -
请求服务端的资源呢是需要在请求头中携带凭证（
Authorization）的，也就是我们常说的token。那我第一次请求的时候呢肯定没有带凭证过去嘛，所以服务端就会返回HTTP Status Code401 Unauthozied并且响应头里会包含:WWW-Authenticate Basic realm="xxx"的标头。 -
那么浏览器就会根据服务端返回的HTTP Status Code 为
401 Unauthozied以及响应头里的:WWW-Authenticate Basic realm="xxx"标头确定该服务端是需要带凭证才能正常访问到资源的，所以浏览器会强制用户进行登录操作： -
登陆后呢浏览器就会自动的将输入的账号密码转成一段
Base64，然后将这段Base64携带在请求头的Authorization标头中，从而能够通过服务端的认证正常访问到资源。 -
而后呢，如果在接下来的请求中，请求资源的地址是跟上面说的服务器是属于同源，又没有手动设置
Authorization标头的话，那么浏览器会将之前生成的那段Base64自动携带到请求头的Authorization标头中（猜测是因为浏览器知道该服务器是需要携带凭证才能够正常访问到资源的，所以浏览器就想：既然你没有设置，那我就擅自给你加上吧，不用谢我~V我50）内心：我谢谢你~。
解决方案
ok，问题到这就算是找出了真正原因了，解决的方式很简单。就是清除一下浏览器缓存就可以了~
搞定收工！！！
