前端覆盖式发布引发的使⽤体验提升
我们公司前端采⽤的是覆盖式发布，过程就是：每次上线时构建好前端项⽬，将构建产物丢给运维，运维直接⽤新构建直接替换掉线上的版本（⼀般⼩作坊应该都是这么搞的...为啥这么搞？我想理由应该是想同的，在此我就不过多解读了）简单粗暴的背后隐患是很⼤的：假设这么个场景，有⽤户a和⽤户b有在使⽤我们的平台，有⼀天某时某刻，a正在使⽤我们的平台，成功登陆后，开始操作balabala，然后a没有关浏览器窗⼝，也没有关电脑，然后出去嗨了...在a嗨的同时，我们公司可爱的前端同学修复了⼀个bug，测试好了之后上线了⼀版，恰巧上线完成之后，b⽤户也来访问我们的平台，跟a⼀样的操作，没有出什么问题，但是a这时候继续使⽤我们平台的时候，问题就来了，发现点击好多页⾯没有反应，万幸的是a会武术，a打开f12后发现好多js⽂件404了？什么 ，我嗨之前不是好好的吗？怎么嗨完回来就gg了...
分析
仔细详细详细，这种场景下，⽤户a的问题是不是偶发还是必然？当然是必然了。。。不要给⽅案上的缺陷找借⼝了。。。现在前端开发⼀般是webpack构建项⽬，在html只会写⼀个⼊⼝的js⽂件，多个页⾯的js⽂件都会被webapck切分代码在配置中映射起来，通过
webpack.require来进⾏懒加载。⽐⽅说⽤户页⾯和设置页⾯，⽤户访问⽤户页⾯（没有打开设置页⾯），这个时候我们修改设置页⾯并更新⼀个新版本，⽤户在打开设置页⾯的时候就会出现js404：⼊⼝js⽂件记录的设置页⾯还是修改前的js哈希⽂件，我们上线后会覆盖掉之前的⽂件，因此⽤户就会报js404错误。。。
解决
发布⽅案估计在很长⼀段时间没得改了。。。那就只能在现有基础上改了。。。在⽹上查找了解到有⼈使⽤ addEventListener 这种⽅法，第三个参数必须为true，使⽤捕获传播（因为是监听资源的错误），如下
window.addEventListener(\"errorrue)
思路就是，如果监听到错误，判断是否为js错误，然后获取js的src值，进⾏⼀次HEAD请求，确认是否http返回状态码为404，如果是404的话提⽰⽤户更新版本（刷新页⾯）后再使⽤：
content=\"width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0\">
Document
