根本原因是浏览器对File API、MediaRecorder、WebSocket等Web能力支持差异；Chrome在文件识别、进度更新、视频播放和内存管理上均优于Edge，后者需手动关闭节省数据、禁用硬件解码、阻止页面休眠方可稳定运行。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
百度一镜数字人本地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分片请求。
生成过程中进度条实时更新是否可靠
第一步：启动本地服务后，在Chrome中打开http://localhost:7860
第二步：上传一个2分钟视频并点击生成
第三步：观察右下角进度提示框——每3秒刷新一次百分比，同时终端日志持续滚动输出“frame 127/489”类信息
第四步：切换到其他Tab页停留1分钟再切回，进度条仍继续更新，未中断
Edge在此环节表现不稳定：当页面被最小化或切换至后台超过40秒，其定时器（setTimeout/setInterval）会被系统级节流，导致前端无法及时接收后端yield返回的状态。此时必须手动点击页面任意区域唤醒渲染进程，进度才恢复更新。
生成完成后的MP4视频预览效果
Chrome可直接在<video>标签内播放H.264编码的MP4，支持seek、音量调节、全屏，且首帧加载延迟低于300ms。Edge对同一文件可能出现解码失败：控制台报错“Failed to load because no supported source was found”，原因是Edge在Windows平台默认禁用软件解码路径，仅依赖硬件加速，而某些集成显卡驱动未正确注册VP9/H.264解码器。
临时修复方式：在Edge地址栏输入edge://flags → 搜索“Hardware-accelerated video decode” → 改为Disabled → 重启浏览器。此操作会降低能效但解决黑屏问题。
长时间任务（>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); });→回车执行。这行代码可阻止页面被判定为不可见，维持连接活性。
