uni-app 微信小程序上传需用 onUploadProgress 手动驱动 CSS 圆环进度条，通过 Math.min 限幅和 ≥2% 防抖避免跳变卡顿；注意左右半圆角度边界处理、transform-origin 及 overflow 隐藏；多端需降级适配，后台时进度停止，前端仅作体验示意。
uni-app 上传文件时怎么实时显示圆环进度条
微信小程序里做上传进度，不能靠 progress 组件原生支持——它只适用于下载或内部加载，对 uni.uploadFile 的实时进度无感知。必须手动监听 onUploadProgress 回调，再驱动自定义圆环更新。
核心难点不在画圆环，而在「进度值怎么从 0 平滑走到 100」：上传接口返回的是已上传字节数和总字节数，但早期阶段（尤其小文件）可能连续几次回调都是 0%，或突然跳到 80%，直接赋值会导致圆环卡顿甚至倒退。
- 务必用
Math.min(100, Math.round((loaded / total) * 100))计算当前进度，避免浮点误差和超 100% - 加一层简单防抖：只在进度变化 ≥ 2% 时才更新
data，否则跳过渲染（减少频繁 setData 带来的卡顿） - 圆环组件推荐用纯 CSS 方案（非 Canvas），因为
uni.uploadFile进度回调频率高，Canvas 在 iOS 小程序中重绘易掉帧，CSS 旋转动画由渲染层优化更稳
为什么圆环进度条在真机上转半圈就停了
这是左右半圆逻辑没对齐的典型表现，尤其在 49%→51% 跨越时。CSS 圆环本质是两个半圆视图叠加：左半圆负责 0–50%，右半圆负责 50–100%；如果角度计算没做边界处理，右半圆会在 50% 瞬间从 0° 跳到 180°，视觉上就像“卡住”或“回弹”。
- 左半圆旋转角度 =
progress （单位：deg） - 右半圆旋转角度 =
progress > 50 ? (progress - 50) * 3.6 : 0 - 务必给两个半圆容器都加
transform-origin: center，否则旋转中心偏移会导致圆环错位 - 微信开发者工具里看着正常，真机上出问题？大概率是
overflow: hidden没写在最外层容器上，导致旋转后半圆溢出被裁剪
uni.uploadFile 的 onUploadProgress 在哪些平台不可用
onUploadProgress 是 uni-app 2.7.14+ 版本才稳定支持的 API，在 H5 和微信小程序（基础库 ≥ 2.19.0）可用，但支付宝小程序、百度小程序、QQ 小程序目前仍不支持该回调——它们只能靠服务端返回「上传完成」后才更新 UI，无法做到真正实时。
如果你的项目要多端发布，得提前做降级：检测平台是否支持 onUploadProgress，不支持就改用「上传中…」文字 + 骨架动画，而不是硬塞圆环进度条。
- 判断方式：
typeof uni.uploadFile === 'function' && 'onUploadProgress' in uni.uploadFile.toString()（简单探测） - 更稳妥的做法是在 manifest.json 中配置条件编译，为不支持平台单独提供静态 loading 状态
- 注意：App 端（iOS/Android）使用的是 native 上传模块，
onUploadProgress行为与小程序一致，但部分旧版基座可能存在回调延迟，建议升级至 HBuilderX 4.20+
上传中用户切后台，进度条还能继续更新吗
不能。微信小程序一旦进入后台，JS 执行会被系统暂停，onUploadProgress 回调立即停止触发，UI 冻结在最后上报的进度值。等用户切回来时，上传可能已完成，也可能失败，但中间那段“空白期”无法补全。
这不是代码 bug，而是平台策略。所以不要依赖进度条数值做关键业务判断（比如“进度到 90% 就允许预览”），所有状态最终必须以服务端回调为准。
- 上传开始前，先存一个本地标记：
uni.setStorageSync('uploading', true) - onLoad 时检查该标记，若存在且未收到成功/失败回调，可提示“检测到上次上传未完成，正在恢复…”（实际是重新发起请求）
- 真正的进度同步必须和服务端长连接或轮询配合，前端圆环只是体验层的“示意”，不是数据源
圆环本身不难画，难的是让它的转动和真实上传节奏咬合。很多人卡在“看起来动了，但动得不诚实”——要么跳变，要么卡死，要么后台一走就失联。这些都不是样式问题，是把进度当成了确定性信号，而它本质上是个带噪声的采样结果。
