当我们谈论浏览器兼容性时，大多数时候我们将其定义为应用程序将支持的最低浏览器版本列表。 e.g：
IE9 +，Firefox 25 +，Chrome 32+等
测试兼容性时，我们通常会测试基线和最新版本。 如果我们想要更广泛，我们可以使用SauceLabs等工具来测试它们之间的所有版本。
我的问题不在于我们是否可以测试兼容性，而是我们应该如何考虑应该支持哪个版本的浏览器。
例如，我遇到了aurelia-polyfills的问题。
无法使用(function(o, s) { ... }(Object, Symbol))在{35}的Symbol is not defined行加载库。
此代码在Firefox 29和最新版本（54）中运行良好。我不知道35之前和之后有多少版本会遇到这个问题。
这个问题，IMO，更多的是与Firefox有关，而不是与库有关，因为它应该将Symbol取消引用为undefined并让代码检查并正确处理它。它类似于IE无法正确处理enum等关键字的问题。
现在，问题是，如果将此视为库的错误或库应该声明不支持这种中间版本的Firefox？
一方面，排除此版本是有意义的，因为它是浏览器的“错误操作”。图书馆作者无法对浏览器提出的任何和所有问题进行殴打。特别是现在，与过去相比，新版本的浏览器更加频繁。有些错误是有限的。
另一方面，这正是“浏览器兼容性”的关键所在，应予以处理。库作者不能忽略它们，因为它们被客户使用。但在这种特殊情况下，它只是不起作用，因为无论何时访问Symbol都会使系统崩溃。
另一点是，当浏览器兼容性表更新时，它将“转移”到那些有问题的版本。
这意味着要么将兼容性表从“IE9 +，Firefox 25 +，...”更新为“IE10 +，Firefox 35 +，...”和“WTF”，要么强制使用更窄的表，例如： “IE10 +，Firefox 52 +，......”。
我认为我们必须咬紧牙关并继续支持“所有最新版本”或在兼容性表中留下一些漏洞并仅支持“黄金”版本。
你会推荐什么？
顺便说一句，我没有反对Firefox，只使用它作为例子。
答案 0 :(得分：5)
我会选择所有浏览器的最新版本，但有一些例外：