响应式瀑布流应放弃scroll监听，改用onReachBottom、IntersectionObserver或LazyForEach等系统级机制，并通过预设图片宽高比、缓存节点测量、加载防抖解耦渲染与请求。
响应式系统处理高频滑动位置计算，核心不是“接住每一次滚动”，而是主动降频、预判和分层响应。瀑布流卡顿的本质，是渲染节奏被滚动事件牵着走，导致重排、重绘、图片加载、状态更新全在主线程里挤成一团。
用生命周期钩子替代 scroll 事件监听
scroll 或 bindscroll 会在毫秒级频繁触发，尤其在快速滑动时，iOS 可能每帧都来一次。这直接拖垮 JS 执行和布局计算。正确做法是放弃监听 scroll，改用框架提供的稳定触底机制：
- uni-app 中统一用 onReachBottom，它由框架节流控制，只在真正接近底部时触发一次
- React 中配合 IntersectionObserver 监听最后一项是否进入视口，不依赖滚动事件
- 鸿蒙中用 LazyForEach + cachedCount，让系统自动管理可视区与缓存区边界，无需手动算位置
位置判断不靠实时滚动值，而靠节点测量与缓存
想准确知道“当前哪项快进来了”，别读 scroll-top，它在安卓机型上不准，且每次读取都会触发强制同步布局。应转向异步、按需的节点测量：
- uni-app 中用 uni.createSelectorQuery().select('.item-last').boundingClientRect() 主动查最后一项位置，比 scroll 事件更准、更可控
- 小程序中避免反复调用 boundingClientRect，对已测过的 item 缓存其 top 和 height，后续仅需对比 scrollTop 即可
- Android RecyclerView 中完全不用算位置——通过 LinearLayoutManager.findLastCompletelyVisibleItemPosition() 直接获取索引
瀑布流布局本身要“去动态高度”
卡顿一大来源是图片加载后高度突变，引发整列重排。响应式系统无法高效应对这种不可预知的 layout shift。解决方案是把“高度不确定性”提前消化掉：
- 服务端或数据层就返回图片宽高比，前端根据列宽直接算出固定高度：height = width × ratio
- 图片容器设 min-height + aspect-ratio（现代 CSS）或内联 style 固定 height，禁止撑开重排
- 鸿蒙中 .height(this.calcHeight(item)) 必须是纯函数计算，不能含异步或 DOM 查询
加载与渲染必须解耦，且带防抖
即使位置判断准了，若每次“进入视口”都立刻发请求、立刻 setData，依然会因并发过多或重复触发导致卡顿。关键在于加一层协调：
- 每个图片加载前先查 loadedMap[src] === true，命中即跳过
- IntersectionObserver 回调中，加载成功后立即 observer.disconnect()，防止重复进入触发
- React 中用 SuspenseList 控制 revealOrder="forwards" + tail="collapsed"，避免未加载项占位跳动
不复杂但容易忽略：真正的流畅，来自放弃对每一次滚动的执念，转而信任系统级的生命周期、观察器和缓存机制。
