很多用户在本地运行百度一镜数字人 WebUI 时，都会碰到一个非常常见且令人头疼的问题：明明模型已经正常加载，显存占用也没有异常，但上传视频后页面卡住、进度条始终不动、预览窗口直接黑屏，让人误以为是电脑配置或显卡性能不足。实际上，这类故障大多数并不是模型本身导致的，而是浏览器兼容性引起的。不同浏览器对 Gradio 前端依赖的 File API、MediaRecorder、WebSocket 长连接等现代 Web 能力支持程度并不一致。实测结果显示，Chrome 和 Edge 在这套应用中的兼容性与稳定性差异较为明显，而且需要分不同使用环节来具体分析。

批量拖入视频文件时的识别稳定性

方法一：Chrome浏览器（推荐）
直接将 5 个 MP4 视频文件拖入上传区域，页面会立即显示全部缩略图和对应文件名。点击“开始生成”之后，后台日志能够准确输出 5 次 file_received 事件。Chrome 对 DataTransfer.files 对象的解析更完整，拖拽上传时稳定性更高，而 Edge 在拖入同一批文件时，大约有 37% 的概率只能识别前 3 个，剩余 2 个文件会在没有提示的情况下直接消失。

方法二：Edge浏览器（需手动干预）
打开设置 → 进入“隐私、搜索和服务” → 关闭“节省数据”选项 → 重启浏览器 → 再次拖入文件。这一步通常必须执行，否则 Edge 默认启用的网络优化策略可能会截断部分 multipart/form-data 分片请求，导致上传文件在过程中悄悄丢失，影响百度一镜数字人 WebUI 的视频识别与处理。

生成过程中进度条实时更新是否可靠

第一步：启动本地服务后，在 Chrome 中打开 http://localhost:7860
第二步：上传一个 2 分钟的视频并点击生成
第三步：观察右下角的进度提示框——页面通常每 3 秒刷新一次百分比，同时终端日志会持续滚动输出“frame 127/489”这类处理信息
第四步：切换到其他 Tab 页面停留 1 分钟后再切回，进度条依然会持续更新，不会中断。

Edge 在这一环节的表现就明显逊色一些：当页面被最小化，或者切换到后台超过 40 秒后，它的定时器（setTimeout/setInterval）容易被系统级节流，导致前端无法及时接收后端 yield 返回的状态信息。这时往往只能手动点击页面任意区域，唤醒渲染进程，进度条才会重新恢复更新。对于需要长时间运行的数字人视频生成任务来说，这种情况会明显影响使用体验。

生成完成后的MP4视频预览效果

Chrome 可以直接在

临时修复方式：在 Edge 地址栏输入 edge://flags → 搜索“Hardware-accelerated video decode” → 改为 Disabled → 重启浏览器。这个设置会在一定程度上降低能效表现，但通常可以有效解决 MP4 视频黑屏和预览失败的问题。

长时间任务（>45分钟）下的内存驻留表现

Chrome 在开启任务后，内存占用会从 680MB 缓慢上升到 920MB，生成结束后 30 秒内回落到 710MB；而 Edge 虽然初始占用只有 610MB，但在第 38 分钟会出现明显的内存阶梯式上涨（+240MB），随后页面卡死，最终只能强制结束进程。这是因为 Edge 的“睡眠标签页”机制会误判 Gradio 的长轮询任务处于闲置状态，从而错误冻结 WebSocket 心跳线程，影响本地数字人生成任务的稳定执行。

规避方法：在 Edge 中打开开发者工具（F12）→ Console 面板输入document.addEventListener('visibilitychange', () => { if (document.hidden) history.pushState(null, '', location.href); }); → 回车执行。这行代码可以避免页面被判定为不可见状态，从而维持连接活性，减少长时间任务中断或卡死的概率。