Chrome vs Edge：哪个更适合运行 Fun-ASR WebUI
在语音识别技术快速落地的今天，越来越多企业开始部署本地化的大模型 ASR 系统。Fun-ASR 作为钉钉与通义实验室联合推出的高性能语音识别方案，凭借其高精度、多语种支持和低延迟推理能力，正被广泛应用于会议纪要生成、客服录音质检、教学内容转录等实际场景。而为了让非技术人员也能便捷使用，Fun-ASR 提供了基于 Gradio 构建的 WebUI 界面——用户只需打开浏览器，即可完成音频上传、实时录音、结果查看等操作。
但你有没有遇到过这样的情况：明明模型服务正常运行，前端页面也加载成功，可点击'开始录音'却毫无反应？或者长时间录制中途突然中断，刷新后历史记录全丢？这些问题往往不在于模型本身，而是浏览器的选择与配置不当所导致的功能异常或性能瓶颈。
尤其是在 Windows 环境下，Chrome 和 Edge 都是 Chromium 内核的主流浏览器，表面上看几乎一模一样，但在处理像 Fun-ASR 这类依赖音频采集、WebSocket 实时通信和 GPU 加速渲染的复杂 Web 应用时，两者的表现其实存在微妙却关键的差异。
从一次真实故障说起
某客户在会议室部署了一套 Fun-ASR 本地系统，用于自动记录每日例会内容。他们使用的是预装 Windows 的笔记本，默认浏览器为 Microsoft Edge。初期测试顺利，但连续运行超过 20 分钟后，系统频繁出现'麦克风断开'提示，且无法自动恢复。更换设备重试仍复现问题。
技术人员排查后发现，并非硬件或网络原因。最终通过切换至 Google Chrome 浏览器，问题彻底消失。进一步分析表明，Edge 在默认'效率模式'下对后台标签页的 CPU 调度进行了限制，导致 Web Audio API 缓冲区未能及时处理音频流，从而引发溢出崩溃。
这个案例揭示了一个常被忽视的事实：浏览器不仅是网页容器，更是决定 AI 应用能否稳定运行的关键环节。
Chrome：开发者首选，稳定性压倒一切
Google Chrome 自诞生以来就以性能领先著称，尤其在开发调试领域几乎成为标准工具链的一部分。对于 Fun-ASR WebUI 这样的工程级应用，它的优势体现在多个层面：
首先是 对 WebRTC 和 MediaDevices API 的极致支持。navigator.mediaDevices.getUserMedia() 是实现浏览器内录音的核心接口，Chrome 不仅最早完整实现该规范，而且在各种外设（如 USB 阵列麦克风、专业声卡）上的兼容性表现最为稳健。
async function startMicrophoneStream() {
try {
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: false });
const audioContext = new AudioContext();
const source = audioContext.createMediaStreamSource(stream);
console.log("麦克风已启用");
return source;
} catch (error) {
.(, error);
error;
}
}
