真正稳定的做法是用scroll-view配合定时器+scrolltop手动驱动，禁用enable-back-to-top，用requestanimationframe控制滚动节奏，ios需$nexttick+平台判断，数据更新时重置逻辑并避免v-for直渲。
uni-app里用scroll-view做垂直滚动公告，别碰swiper
垂直滚动公告的本质是「单列、自动、无缝、可暂停」的文本流，swiper在uni-app中垂直模式下存在滑动卡顿、无法精准控制滚动速度、touch事件干扰等问题，尤其在iOS真机上容易出现滚动中断或回弹异常。真正稳定的做法是用scroll-view配合定时器+scroll-into-view或scrollTop手动驱动。
实操建议：
- 给
scroll-view设scroll-y和固定高度，禁用enable-back-to-top（避免iOS下意外跳回顶部） - 内容区用
view包裹多条text，每条末尾加一个空行（用于视觉缓冲），总高度需大于容器高度才能滚动 - 不用
scroll-into-view做逐条切换——它会触发布局重排，导致抖动；改用scrollTop累加像素值平滑滚动 - 滚动到底部后，重置
scrollTop为0并forceUpdate（this.$nextTick后操作），实现“无缝”循环
滚动速度和暂停逻辑怎么写才不卡、不跳帧
直接用setInterval每50ms加1px，看似简单，但在低端安卓机上容易掉帧；更稳的方式是监听requestAnimationFrame，结合时间戳计算偏移量，保证60fps节奏。
常见错误现象：scrollTop突变导致页面闪一下、暂停后再启动位置错乱、快速切后台回来滚动失步。
实操建议：
- 用
let startTime = 0, elapsed = 0, baseTop = 0记录滚动状态，每次raf回调里算差值，再更新scrollTop - 暂停时只暂停
raf调用，不清除elapsed，恢复时从断点继续，避免跳帧 - 鼠标悬停/触摸时暂停，但要在
touchstart和mouseenter两个事件里都处理，H5和App端行为不一致 - 别在
scroll-view上直接绑@scroll——滚动中频繁触发会拖慢主逻辑，仅在重置或调试时临时启用
真机兼容性：iOS和Android的scroll-view表现差异
Android下scroll-view的scrollTop设置基本即刻生效；iOS（尤其是iOS 15+）有渲染延迟，直接赋值可能被忽略，必须配合this.$nextTick或短延时。
使用场景：你发现模拟器跑得好好的，一上真机就卡住或不动，大概率是这个原因。
实操建议：
- iOS平台检测用
uni.getSystemInfoSync().platform === 'ios' - 设置
scrollTop前加await this.$nextTick()（Vue 2需用new Promise(resolve => this.$nextTick(resolve))） - 避免连续多次
scrollTop赋值，合并为一次，否则iOS会丢弃中间值 - 如果公告内容含emoji或富文本，iOS下
text行高计算不稳定，统一用line-height: 1.5内联样式锁定
数据动态更新时，怎么避免滚动突然重置或错位
公告列表变了（比如后台推来新消息），直接uni.setStorageSync更新data后，scroll-view不会自动适应新高度，旧的scrollTop可能超出范围，导致空白或卡死。
性能影响：每次更新都重新计算全部高度，对长列表很伤；兼容性影响：App端scroll-view在v-for更新后可能不触发ref重绑定。
实操建议：
- 新数据到来时，先
clearInterval或取消raf，等$nextTick后再重启滚动逻辑 - 用
uni.createSelectorQuery()查新内容总高度，和当前scrollTop比对，若超出则重置为0 - 不要用
v-for直接渲染原始数组，包一层computed，末尾自动拼一个重复首项（用于无缝衔接），避免重绘时闪烁 - 上线前务必在iOS真机+微信小程序双端测试「连续推送3条公告」场景，这是最容易暴露重置bug的地方
最麻烦的其实是滚动节奏和视觉缓冲的匹配——行高、间距、滚动速度、暂停时长，四个参数稍一失调，用户就会觉得“卡”或者“太快看不清”。这些没法靠代码自动适配，得实测微调。
