这就是原因
它违背了网络标准的精神
网络标准存在的全部原因是为了让我们不必为特定环境编写特定代码。 我们应该编写符合既定标准的代码，负责显示我们代码的软件应该按照标准指示显示它。
它依赖于浏览器用户代理字符串
… 具有 极其糟糕的历史，并且很容易被欺骗。
它可能会阻碍设备
示例：您检测到 iPhone 并为其提供特殊内容。 现在 iPhone 永远无法像其他浏览器那样看到网页，尽管它完全有能力这样做。
那我们为什么要这样做呢？
我们这样做是因为不同的浏览器处理事情的方式不同，浏览器检测可以让我们摆脱困境，并使事情按预期工作。 你不能怪我们，对吧？
通常导致我们诉诸浏览器检测的情况令人愤怒。 但请记住，通常不是浏览器出了问题。 即使是 IE 6，在发布时也是当时最符合标准且最先进的浏览器。 而我们今天的一些标准当时还没有完善。
我们应该怎么做？
我第一个承认，现实世界的网页设计有时需要快速修复、预算可接受的解决方案，并确保功能按预期工作。 这并不总是允许做出利他主义的选择，而这些选择会排除一些功能，因为这是“正确的事”。
理想情况下…
… 我们将进行 **能力测试**。 这才是我们真正需要的 信息，对吧？ 测试我们所在的 环境是否能够满足我们想要做的事情。 如果可以，就去做。 说起来容易做起来难，我敢肯定，我自己都不知道该从哪里开始。 但我相信你们中的一些人非常聪明，可以完成它（或者已经完成了它！）
更多
这里有一些关于 能力测试 的内容来自 Quirksmode。 这里还有 Dave Shea 的 一个很好的例子，说明了为什么浏览器检测不好。
Chris,
您是赞成还是反对使用浏览器检测来提供不同的样式表？
例如：我目前使用 HTC Wizard（O2 Xda Mini II S），而一些网站（即使那些带有移动样式表的网站）看起来也很糟糕，因为图形大小调整了，固定大小对于屏幕来说太宽等。
我个人更喜欢检测移动设备的 UA，并为大屏幕手机（Win Mobile 设备、LG Viewty）和小屏幕手机（Sony Erricsson C905）提供不同的样式表。
仅供参考
Chris
我不使用浏览器检测，而是使用屏幕宽度检测。 我从适合瘦屏的样式表开始，然后使用 js 检测宽度，并在需要时更改样式表。
那么你为什么要使用 `<!--[if IE 6]>...<![endif]-->` 和 `<!--[if IE 7]>...<![endif]-->`？
我更愿意做
哈哈！
:)
是的，这样好多了。 但由于我们无法以这种方式做事，因此浏览器检测是唯一的选择。
右键单击，查看源代码
条件注释仅由 IE 执行，所有其他浏览器都将它们视为任何其他注释。 因此，使用它们意味着 IE。 这样，它们也是一种隐含的能力检测：请注意，它们嵌套在注释标签中。 这类似于（但不完全相同）说
当我们通常进行能力检测时，有一些技术会无意中 **能够**识别浏览器，例如检查事件监听器。 在这里，我们只是利用了这样一个事实：如果此条件执行，那么浏览器就是 IE。 Chris 所写的浏览器检测使用的是 javascript，并使用内置方法，这些方法不足以真正检测客户端身份。 而且，这些方法要求浏览器未来的更改意味着代码的完全重写。 能力检测允许未来浏览器在今天缺乏标准合规性的情况下进行标准合规性。 使用条件注释，我们还可以轻松地替换指向 css 文件或 js 文件的链接，或者类似的东西。 因此，虽然您指出 CC 检测到浏览器，但它们的使用比使用传统的浏览器检测方法要好得多。
帖子标题太宽容了。 您可以使用浏览器检测来改善用户与您网站的交互。
简单示例。 如果我在页面上有一个文件上传输入，让用户知道他可以将文件拖放到输入框中将是一件好事。 但这仅仅是 Chrome 和 Safari 的功能。 因此，我必须使用浏览器检测或浏览器特定的 css 技巧。
这正是重点，检测 **浏览器是否能够进行拖放** 而不是检测浏览器本身会更好吗？ 这样，当一个新的浏览器出来支持它时，你已经准备好了。
我并不完全同意这篇文章的标题，但我确实看到了 Chris 的观点。 浏览器检测和操作用户代理字符串确实有其优点，例如检测互联网上的隐藏和恶意行为。:)
用户代理检测很糟糕。基于功能的检测很好。
David，你总结得很好。我完全同意。
说得很好！我认为这应该是标题内容。:)
这真的应该是文章的标题！
我也认为我理解了你的意思，但目前我还是希望有些网站能在有可用选项时提供简洁的移动版网站。也许像 Twitter 这样的网站做得很好，它们默认使用手机版网站，但会提供标准视图的选项……更棒的是，网站可以记住用户的偏好，并根据每个人的偏好提供相应的内容。
我认为我理解你想要表达的意思，在很大程度上我同意你。但我认为互联网存在的意义是尽可能好地获取信息。我认为针对一种设备的最佳解决方案并不一定是针对另一种设备的最佳解决方案。例如，iPhone 和宽屏显示器。Amazon 就是一个这样做网站的例子。当你第一次在 iPhone 上访问该网站时，它会把你带到 iPhone 页面，并提供一个选项来转到“电脑”页面。因此我认为，功能测试和设备检测都是不错的解决方案。但这仅仅是我的拙见。
……很糟糕，而且不可避免（就像命运一样）。感谢微软！
可能很糟糕，但有时是必要的。
我可以在哪里下载 IE6 来测试网站？
如果你使用的是 Windows，可以使用 IETester：http://www.my-debugbar.com/wiki/IETester/HomePage
由于某种原因，IE tester 没有给我合适的 IE6 结果。所以我在 Windows XP 中使用独立的 IE6 以及 IE7，这是独立 IE6 的链接：http://tredosoft.com/Multiple_IE
我最近使用黑莓浏览器的经历正在改变我对浏览器检测的态度。
http://supportforums.blackberry.com/rim/board/message?board.id=browser_dev&thread.id=817
有时你只需要知道你何时在处理一个有问题的软件。
你对浏览器特定的 CSS 有什么看法？随着维护的进行，这似乎是必要的恶。
我认为这的确是必要的恶。CSS 本身并不具备浏览器检测或功能测试的能力，所以这几乎是我们唯一的选择。
我想我说的更多的是 JavaScript 检测（或者任何可以检测用户代理字符串并采取相应措施的方法），以及重定向或提供特殊内容或类似的东西。
关于 JS 用户代理检测和提供“特殊内容”，我想向你提个情况……
假设你是一家大型公司，并且是标准进步和网络开发的领导者。也许是一家像 Google 这样的公司，哈哈。;P
假设你想“尽一份力量”鼓励用户放弃 IE6，转而使用 FF、Chrome 或 WebKit。
除了浏览器检测，你打算如何做出显示“升级以获得更好的服务”通知的决定？
这只是一个简单的情况，但你明白我的意思。而且也是真的。
再说一次，Google 完全支持表格布局，不使用 DOCTYPE 声明，并使用像<center>这样的已弃用标签。我猜规则是这样的：如果你想让每个人都能在任何电脑（尤其是旧的电脑和浏览器）上访问你的网站，就使用旧的标记。就像 97 年一样进行设计……
Chris，我不得不礼貌地不同意你的观点。很多时候，“功能检测”就是通过“浏览器检测”来完成的。
我认为你应该始终提供相同的内容（X）HTML，无论访问设备是什么。网站至少应该可以在 Lynx 中使用。
关于 CSS（表现层）的决定绝对应该取决于浏览器。以你的例子为例：iPhone。虽然你可以使用 iPhone 访问相同的网页，但能够提供一个适应设备的界面无疑会受到重度移动用户的欢迎。这里想到的是导航。大手指 + 小屏幕 = 难以导航，即使用户的设备“可以”显示“真实的”网页。
此外，关于条件样式（例如 IE6），偶尔进行一些调整并没有什么错。我绝不会说人们应该“迎合”IE6。但你真的需要考虑渐进增强，有时你无法真正“检测”功能，除非先检测浏览器。
然后，当然还有你的行为层。虽然使用 Prototype、jQuery 等 AJAX 框架，我们已经在远程调用方面消除了 IE 和其他一切之间的差异。这种直接使用 JS 的功能检测在很大程度上非常容易：要么开启，要么关闭。
然而，真正非常繁重的客户端处理仍然会受到移动端的影响。如果你知道你的用户使用的是移动浏览器，因此使用的是一款性能非常低的移动设备，你可能不想将大量处理从服务器转移到客户端。iPhone 非常强大，但像所有其他智能手机一样，在处理器和内存方面存在很大不足。
我理解你想要表达的意思；然而，它听起来在理论上很严格，但在实践中并不利。正如另一位发帖人所说，你自己也使用浏览器检测来处理 IE 问题。;P
第一个移除浏览器嗅探的 JavaScript 库是 1.3 版本的 jQuery。
一个有趣的故事是，在 The Ajax Experience 上的一次小组讨论中，John Resig 提及了移除浏览器嗅探，结果被大家嘲笑。他们说这不可能，事实是他做到了！
我完全同意！
所以使用 Firefox 在家里的用户应该获得与使用黑莓的用户完全相同的纽约时报网页吗？屏幕尺寸完全不同。黑莓上的 JavaScript 支持参差不齐。
我敢肯定这不是 Chris 的意思，他为什么说应该进行功能检测而不是浏览器检测。其中一项要检测的是窗口大小，假设你的用户将使用有史以来最小的、最糟糕的浏览器，然后从那里向上调整。通过使用 JavaScript，你或多或少可以确定用户的浏览器/显示屏性能，并使网站相应地更改样式表。
当然，这假设你可以使用 JS 来检测这些东西。
在用户禁用 JS 的极少数情况下，接下来最好的选择是在服务器端使用用户代理字符串。
而在用户禁用 JS 并伪造用户代理的更少数情况下……好吧，就让事情顺其自然吧。假设，只要确保所有内容都可以访问，并且整个网站基本上可以在没有 JS、没有 CSS 和没有图片的情况下正常工作。
如果你说的是使用 JavaScript 进行检测，我认为大多数框架都使用功能检测。例如，Mootools 会确定浏览器引擎。以下是检测 trident（Internet Explorer）的示例：
return (!window.ActiveXObject) ? false : ((window.XMLHttpRequest) ? 5 : 4);
如果在 IE 中，它会将 Browser.Engine.trident 设置为 trident4/trident5。
但告诉 IE 用户他们的浏览器很糟糕感觉真好……
当然，我反对不允许使用糟糕浏览器的用户访问网站，但无论如何，我仍然可以私下告诉他们……
在我的网站上（http://www.loriskumo.com），我使用了一个位于右上角的小图片来邀请访问者使用 FireFox 而不是 IE。但如果他们不想，他们仍然可以访问网站。
这就是我所说的我与 IE 进行的小斗争……
不错的文章……检测浏览器真是太痛苦了！
jQuery 不再使用浏览器嗅探，正如 Chris 提到的，他们使用功能检测来避免未来的麻烦和问题。抱歉，如果有人提过，但我没有看到。
在 handsetdetection.com，我们使用用户代理和其他标头来提供移动/手机的功能。
我不同意你关于特殊内容是邪恶的断言。
如果客户想要一个针对 iPhone 优化的体验，那为什么不提供给他们呢？当然，iPhone 可以显示正常的内容，但为什么不针对 iPhone 定制体验呢？
我认为当你使用浏览器检测来检测用户是使用 PC 还是 iPhone 时，这完全没问题。可能你可以把它看作只是用来检测使用的设备或机器的一种方法，而浏览器本身并不重要。
我认为针对 iPhone 的浏览器检测很有用。我很快就会有一个完整的 Flash 网站——永远不会——所以我想把它作为备用……但我懂什么……反正我对这些东西一窍不通
但 IE6 对我来说太糟糕了。我刚开始接触设计世界……IE6 不属于我的时代，我可以这么说……我不用任何东西来解决 IE 的问题……就这样吧……也许这不好……但至少这样可以发出“不要使用 IE”的声明。
我同意浏览器检测很糟糕。我只想分享这个浏览器检测出大错的例子。Ubiquity 扩展的版本被视为 Firefox 的版本：http://flickr.com/photos/spiri/3274163228/
我不完全理解功能检测。
我的脚本中的大部分浏览器检测代码都是为了解决非常罕见的浏览器错误，通常一次只针对一个浏览器。
我怀疑库会检测到所有这些小浏览器错误，然后把它们标记为我需要检查的功能。如果多个浏览器实现了某个功能，但其中一个在某些地方有错误，而我需要以不同的方式处理它怎么办？
我认为我会最终不得不获取并测试多个功能，这样我才能针对特定浏览器并尝试修复错误。最终，它仍然是浏览器检测，但它是通过查看功能来确定我正在使用的浏览器的一种迂回方式。
我理解它如何让我们摆脱对用户代理字符串的信任来检测浏览器。无论哪种方式，我仍然需要一种方法来进行浏览器和版本检测，无论是通过检测用户代理字符串还是功能检测。
我很想看到库保留浏览器检测功能，但以功能检测为基础。为我们提供更准确的浏览器检测，让我们根据最适合我们的方式使用它或功能检测。
我知道这是一个旧主题，但它仍然出现在 Google 的顶部。
对于某些衬线字体，Firefox 的字体渲染比 Chrome 或 Safari 的字体渲染要密集得多。专门针对 Firefox 调整 css letter-spacing 属性对可读性有很大影响。
在这种情况下，浏览器检测很有用，除非有人能提出更好的方法？