转自：https://zhuanlan.zhihu.com/p/24091492
2015年不支持IE6/7
2015年年底，天猫和淘宝一起推动完成了IE6/7不支持项目，当时不支持的主要原因有：
从16年1月20号开始，微软不再支持IE7/8的升级（14年4月8号就停止了对IE6的升级支持）对于这部分用户如果不升级到最新的浏览器，未来如果报出漏洞，可能会导致用户数据出现泄漏。
前端开源社区技术方案基本都已不再考虑IE6/7，如果还要继续兼容IE6/7，对于开发效率提升、技术方案简化都是一个非常大的阻碍。
https相关的原因，SHA-1签名的证书被证明已经可以在短时间内破解，所有证书供应商从16年1月1日开始不再签发SHA-1签名的证书，所有浏览器和操作系统也会将SHA-1证书标记为不安全，受影响的用户主要包括使用Windows XP SP的IE用户和Android2.3版本以下的用户。
除此之外，以上这些用户还会因为不支持HSTS（非常容易被劫持）、前向加密（也就是RSA交换的密钥未来可以被破解）、TLS1.2（更安全）、SNI（方便运维，否则需要维护很多ip地址）、session ticket（提高性能，降低服务器消耗）, OCSP stapling（获取证书状态，提高性能和安全性）等特性，给我们在安全、性能、运维上带来很大的麻烦。
当时的总结里，我们写了这样一句话：
期待IE8/9也成为历史的那一天
看起来，这一天比我们想象的来的早一点。
为什么考虑不支持IE8
2016年双11结束了，回顾2016年，天猫前端彻底从KISSY时代迁移到了符合Web标准的开发模式，也在业务中落地了包括Weex、React及周边的配套，尝试将整体的技术方案和开源社区做更多的结合。这部分可以参考《天猫前端基础技术体系MAP简介》 。
而随着整体技术方案的推进，IE8慢慢也变成了一个问题，从Promise里的.catch()和IE8的关键词冲突，到IE8 defineProperty/getOwnPropertyDescriptor的问题，还有部分版本的uglify打包的时候打出了类似var a = function a(){}这样的代码，导致的IE8下各种变量混乱。这些问题的暴露一部分原因是工具和配套没有跟上，在开发期没有暴露问题出来，另一方面也说明了社区对于IE8的降级及复杂方案的简化态度。
这些积累的问题，可以通过增加各种兼容手段，各种工具在打包的时候做各种检查进行规避。但是反过来思考，这些问题也是一个契机，是否到了不支持IE8的时机了？
如何决定不支持IE8
接下来，就是明确不支持IE8这个事情要不要执行了。其中，对于技术上的益处，显而易见，但是对于用户的影响也是必须要考虑的。所以，还是需要各种考虑目前的数据和微软官方的策略，这些对于决策来说非常重要，基于数据和事实描述问题也更能说服业务方。
数据
基于2016年11月份对天猫整体浏览器分布的分析和统计，目前IE8的占比情况已经非常类似2015年IE6/7的情况，加上无线端流量远超PC端流量，对于大盘来说，IE8这部分的数据已经非常小。
微软官方的策略
微软对自己的产品都定义了明确的生命周期，而IE的生命周期则是和所对应的windows操作系统绑定。
从 2016 年 1 月 12 日开始，仅适用于受支持操作系统的最新版本的 Internet Explorer 才能获得技术支持和安全更新，如下表所示：
其他浏览器终止支持意味着不再提供安全更新、非安全更新、免费或付费的协助支持选项或联机技术内容更新。
安全相关
2016.1.1 之后不再签发SHA-1证书，证书到期后，xp用户（包含xp ie8）访问将安全alert
The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016
上线计划
目前天猫首页已经在页面顶部对IE8的用户进行了即将不支持的提示。
在双12结束之后，将开始部署IE8覆盖全屏的浮层进行用户引导，浮层也将不能关闭。由于天猫页面&系统繁多，确认各个具体业务的影响及进行业务部署将花费较长的一段时间。
目前除了IE8之外，我们在IE9/10上也放了建议用户升级浏览器的提示。接下来也期待一下IE9/10成为历史的那一天。
最后
作为前端，提供用户更好的体验的手段不仅仅是提升页面性能，能够引导用户，推动用户选择更合适的访问终端，也是重要的方式之一。
