其实直接靠User-Agent字符串或者纯前端JavaScript来精准识别这类预发布的开发者浏览器，确实是个挺头疼的事儿——毕竟Chrome Canary、Edge Dev/Beta、Firefox Nightly这类版本的UA里，大多不会直接带着"dev"或者"developer"这种一眼就能识别的关键词，而且也没有什么统一的规则能直接套用。

我给你梳理几个可行的思路，你可以根据自己的场景来选：

1. 从User-Agent的版本号或隐含标识下手 #

虽然没有明确的关键词，但这些预发布版本的UA里还是藏着一些小线索的：

• Chrome Canary的版本号会比当前稳定版超前好几个大版本，比如现在稳定版是124，Canary可能已经冲到126了；
• Firefox Nightly的UA里版本号会带a1后缀，比如Firefox/125.0a1；
• Edge的Dev/Beta版，UA里的版本号也会比稳定版高，部分Beta版可能会在UA里带Beta标识（不过这个不是绝对的，得看厂商的更新策略）。

但这个方法有个明显的问题：版本号是动态变化的，你得时刻跟进各大厂商的版本迭代节奏，而且不同平台的UA可能还有差异，维护起来挺费劲儿的，没法一劳永逸。

2. 检测实验性API或行为差异 #

有些预发布版本会提前启用一些还没推到稳定版的实验性API，你可以试着检测这类API是否存在来判断。比如某个新的DOM API，只有Canary或者Dev版才支持，稳定版还没上线。不过这个方法的风险也不小——等稳定版推了这个API，你的判断逻辑就直接失效了，而且不同厂商的预发布版启用的实验API也不一样，维护成本很高，只能作为临时方案。

3. 绕开浏览器检测，从需求根源解决问题 #

你核心需求是给有权限的开发者显示诊断信息，那其实没必要死磕浏览器版本判断。比如：

• 整个内部人员才知道的触发方式：比如按特定快捷键（比如Ctrl+Shift+D），或者在URL里加个内部参数（比如?showDebug=true），让开发者主动开启诊断信息；
• 配合企业域管理：如果你们公司是域环境，其实可以让桌面管理工具给开发者设备打个标记，然后通过后端接口把这个标记传给前端，前端再根据标记显示诊断信息——这个比浏览器判断靠谱多了，毕竟开发者设备的权限是明确的。

你之前考虑的用户组方案确实容易遇到维护滞后的问题，所以换个主动触发或者设备级别的标识方式，会比依赖浏览器版本稳定得多。

备注：内容来源于stack exchange，提问作者mnemotronic