浏览器检测与功能检测
我会暂时扮演魔鬼的主张。 我一直在想，为什么浏览器检测（而不是功能检测）被认为是一个糟糕的做法。 如果我测试某个浏览器的某个版本，并确认，某些功能的行为是以某种可预测的方式，那么决定做特例似乎是可以的。 原因是将来会万无一失，因为这部分浏览器版本是不会改变的。 另一方面，如果我检测到DOM元素具有函数X，则不一定意味着：
- 这个功能在所有的浏览器中以相同的方式工作
- 更重要的是，即使在所有未来的浏览器中，它也将以相同的方式工作。
我只是窥探jQuery源代码，他们通过插入一个精心构造的HTML代码片段到DOM中进行特征检测，然后检查它是否具有某些特征。 这是一个明智而可靠的方法，但是我会说如果我在我的一小段个人JavaScript（没有jQuery）中做了这样的事情，那将会有点过重。 他们也具有实际无限的质量保证资源的优势。 另一方面，你经常看到人们做的是他们检查函数X的存在，然后在此基础上，他们认为函数将在所有具有这个函数的浏览器中以某种方式表现。
我没有说任何特征检测不是一件好事（如果使用正确），但我想知道为什么浏览器检测通常立即被驳回，即使这听起来合乎逻辑。 我不知道这是否是另一个时髦的事情。
自从几年前Resig 发布这个帖子以来，浏览器检测已经被广泛的忽视了。 然而，Resig的评论是针对库/框架代码的，即其他[特定领域]应用程序/站点将使用的代码。
我认为功能检测毫无疑问是适合图书馆/框架的 。 对于域特定的应用程序，但我不太确定浏览器检测是不好的。 它适合于处理难以识别的已知浏览器特性，或者对于在其特性本身的实现中存在缺陷的浏览器。 浏览器检测适用的时间：
- 网站/应用程序不是跨浏览器，需要显示一个警告/对话框/不同页面剪裁到该客户端的浏览器。 这在遗留应用程序中很常见。
- 银行或私人网站对支持哪些浏览器和版本有严格的政策（以避免已知的可能危害用户数据的安全漏洞）
- 微观优化：偶尔一个浏览器以某种方式执行一些操作时比其他浏览器更快。 根据您的用户群来分发特定的浏览器/版本，这可能是有利的。
- 在IE6中缺乏png的透明度
- 许多显示/渲染问题（阅读：IE CSS支持），只有在特定的浏览器版本见证，你实际上不知道什么功能来测试。
也就是说，在浏览器检测时有一些主要的缺陷 （可能是我们大多数人犯的）。
这里有一篇很好的文章解释了如何在很多方面浏览器嗅探特征检测的优越性。
事实是，嗅探是非常脆弱的。 理论上它是脆弱的，因为它依赖于一个任意的 userAgent字符串，然后实际上将该字符串映射到某个行为。 正如时间所显示的那样，它在实践中也是脆弱的。 测试几十个浏览器的每个主要版本和次要版本，并试图解析其中一些版本的内部版本号是不实际的; 另一方面，测试怪癖的某些行为则更加健壮。 例如，功能测试常常会发现浏览器供应商偶然拷贝的错误和不一致之处。
从我自己的经验来看，在IE8中修改Prototype.js，我知道如果我们一开始没有嗅探，就可以避免90％的问题。
在修复Prototype.js的同时，我发现需要测试的一些功能在JS库中是非常普遍的，所以我为那些愿意摆脱嗅探的人做了一些常见的功能测试 。
理想的解决方案是将功能和浏览器检测结合起来。 前者因为你提到的点而倒下，后者是因为有时候浏览器发布虚假信息来“使事情有效”。
Mozilla有一个伟大的浏览器检测入门 ，这也可能对你有所帮助。
来自维基百科 “在历史的不同阶段，网络的使用已经被一个浏览器占据主导地位，许多网站只能用于特定的浏览器，而不是像W3C和IETF这样的机构的标准。这些站点通常包含“浏览器嗅探”代码，这些代码根据接收到的用户代理字符串改变发送的信息，这可能意味着不太流行的浏览器不会发送复杂的内容，即使它们能够正确处理，或者在极端的情况下拒绝了所有的内容，因此各种浏览器“欺骗”或者“欺骗”这个字符串，以便将自己标识为这种检测代码的其他内容;通常，浏览器的真实身份随后被包含在字符串中。
