关于 crossorigin 引起的一系列化学反应

[winixt]

在我脑海中 crossorigin 一直都是 script 上非常成熟的一个属性，可以非常好的解决跨域脚本的异常上报问题。实际使用之后，发现不是这么回事。

背景

通过监控平台，我看到一个项目有些 Scritp Error 异常，因为是跨域脚本拿到不到具体的异常信息。于是我在一个版本中给脚本加上 corssorigin 属性，希望能捕捉到具体异常。

发到预发布环境后，业务方反馈有些用户打开页面白屏，只显示一个标题。（离谱，我就改了一行代码）

排查1

在测试同学的帮助下，在测试环境复现出来了。抓包发现，页面白屏的时候只请求了 html 文件。新的脚本文件一个都没请求，也没接口调用，没有脚本异常。麻了。清了微信缓存再试了下，可以了。但是后面在也没复现出来。（后面才发现，微信在手动清理缓存之后，短时间内不会再缓存问题，即使带来了 max-age 也不缓存）。

猜测

1. 微信近期的版本，对缓存的处理有问题
2. 新增的 crossorigin 属性，在微信上有问题

排查2

升级了下最新版本的微信（出现白屏的是最新的微信），都没有复现。后面让出现白屏的用户访问带 corssorigin 的测试环境页面，出现白屏！重新部署不带 corssorigin 的版本，正常渲染。

可见是 corssorigin 属性的锅。但是这不是一个常规属性吗？

关键时刻还得万老板出马

万老板找到这篇文章里面关键的一句话:

缓存的图片如果是未设置跨域属性的图片，html-img标签设置了crossOrigin属性，从缓存加载，会触发跨域问题。

前端 H5 页面是增量打包的，意味着这次发版，有些 js URL 是不变的，命中了上述描述。mock 了下环境，确实微信稳定复现了。我不理解，为什么不去重新加载～试了下浏览器之王 Chrome，发现也一样～

一个有趣的 issues

去 Chrome issues 上搜了下，发现一个有意思的issues

这里简单总结一下 Chrome 的观点，感兴趣的可以去翻原文（建议看看，还是很有意思的）：

• Chrome 的实现是比较符合规范的
• 缓存的资源如果是没有设置跨域属性，后面加上了 crossOrigin 属性，引发跨域问题，属于已知不修复 Bug。
• 有两种解决这种问题思路：1）设置可跨域访问的静态资源，服务器都一直带上跨域头部，无论是否触发跨域。2）服务器设置 Vary Header，告知浏览器不缓存 Response Header，而是去服务器获取新的。

终

1. 跟腾讯云 CDN 协商，能否采用 Chrome 建议的方式处理 CORS Header（这个优点难，亚马逊就不太同意）
2. 加 crossOrigin 属性的时候，确保所以资源都是新的 url，不会命中历史缓存