最常见原因是done回调未显式调用element.progress设为100%，导致进度条卡在99%或不消失；progress中n===100仅表示数据发完，done才是上传成功信号，必须在此处手动拉满进度条并同步UI状态。
done回调里没调用element.progress设为100%
进度条卡在99%或不消失，最常见原因是done回调里漏掉了手动把进度条拉满的操作。layui的element.progress()不会自动归零或归满，它只响应你传进去的值。
-
progress回调里的n === 100只表示浏览器已发完数据，不代表服务端处理完成 -
done才是上传成功的唯一信号，必须在这里显式调用element.progress("demo", "100%") - 如果用了动态
lay-filter（比如"progress-0"），done里得传对应标识，不能硬写死"demo" - 别忘了同步更新UI状态：隐藏loading图标、启用提交按钮、显示成功提示
progress回调里提前清空或重置了进度条
有人在progress函数里写了element.progress("demo", "0%")或误调layui.element.init()，导致每次回调都重置——这会让进度条反复跳回起点，最后停在某个中间值不动。
-
layui.element.init()是全局初始化，不是刷新单个进度条，严禁在progress里调用 - 进度条应只由
progress回调更新数值，done或error回调收尾 - 若需“重试后清空”，应在choose或重新触发上传前单独调用
element.progress("demo", "0%")
多个文件共用同一个lay-filter导致覆盖
表格内批量上传或多文件同时上传时，如果所有进度条都写lay-filter="demo"，后一个文件的progress会直接覆盖前一个，最终只有最后一个文件的进度可见，其他进度条看起来“消失了”。
- 每个文件必须绑定唯一
lay-filter，比如"upload-progress-" + index -
progress和done里都要用相同标识调用element.progress() - HTML中要预先生成对应数量的进度条DOM，或动态插入——不能只写一个静态节点
IE或旧版Edge不支持upload.onprogress
IE10以下、部分旧版Edge根本没实现XMLHttpRequest.upload.onprogress，progress回调压根不会触发，自然也不会进done去清理进度条。
- 检查
navigator.userAgent，对不支持的浏览器降级为轮询方案或隐藏进度条 - 服务端需配合提供
/api/progress?fileId=xxx接口，前端定时查状态 - Nginx或PHP的上传限制（如
client_max_body_size）也可能让请求中途断开，表现就是进度停在99%，此时done和error都不触发——得查服务端日志
n === 100就以为结束了，结果服务端还在校验、转码、写磁盘，用户看到的却是静止的99%。 
