该停。iOS/Android后台会冻结WebView或限制定时器，导致swiper自动播放卡顿、跳帧、内存占用；应监听uni.onAppHide/onAppShow手动暂停/恢复，并缓存current值防错位。
uni-app 里用 swiper 轮播图片，但切到后台就该停吗？
该停。iOS 和 Android 系统在 App 进入后台后会冻结 WebView 或限制定时器执行，swiper 的自动播放（autoplay）若依赖 setInterval 或页面生命周期外的逻辑，大概率失效或错乱——不是“轮播没停”，而是“轮播卡住+恢复时跳帧+内存持续占用”。真正要做的，是主动监听前后台状态，手动控制播放开关。
怎么监听 uni-app 页面是否在前台？
别靠 onShow/onHide ——它们只管页面级显隐，不反映整个 App 是否在后台。必须用 plus.navigator.getState()（仅 5+ App）或更通用的 uni.onAppHide/uni.onAppShow。
-
uni.onAppHide触发时，立即调用swiperRef.pause()（如果用了 ref）或设置autoplay: false并记录当前索引 -
uni.onAppShow触发时，再恢复autoplay: true，并用this.$nextTick(() => swiperRef.resume())避免 DOM 未就绪 - H5 端用
document.addEventListener('visibilitychange')补充监听，document.hidden为true时同样暂停
swiper 组件的 autoplay 参数有哪些坑？
autoplay 看似开关，实则受多个条件制约：
- 必须同时设置
interval（毫秒），默认 5000，设成 0 不代表关闭，而是“立即切换”，容易卡死 - Android 真机上，若
duration（滑动动画时长） >interval，会导致轮播“粘连”——上一帧还没动完，下一帧已触发 - 微信小程序平台不支持
autoplay动态修改，改了也不会生效；得用current+ 定时器手动控制，再配合change事件防抖 - 开启
disableProgrammaticAnimation可避免手动current切换时与自动轮播冲突，但会丢失过渡动画
后台停止后如何省电又不丢体验？
单纯停掉 autoplay 不够。轮播组件内部可能还挂着定时器、图片预加载、懒加载回调等。
- 在
onAppHide中，除了暂停 swiper，还要clearInterval(this.timer)（如果你自己写了轮播逻辑） - 用
lazy-load属性控制图片加载，避免后台时仍请求未显示项的src - 轮播图数量超过 5 张时，建议用
virtualList模式（需自定义实现或用插件），否则 DOM 节点和内存占用随图片数线性增长 - iOS 上，
backgroundAudioManager类似的机制不存在，所以不要试图用音频 hack 唤醒定时器——无效且被系统 kill
最常被忽略的是：App 切后台时，swiper 的 current 值不会自动同步到 data，恢复前台后直接开播，可能从错误位置开始。务必在暂停前缓存 current，恢复时先设值再开播。
