Jetpack Compose Paging3实现LazyColumn粘滞头部异常问题

当前实现存在两个核心错误：

• 直接在LazyColumn组合阶段对itemSnapshotList.items全量执行groupBy+forEach，彻底破坏Paging的懒加载触发逻辑：Paging依赖列表对靠近尾部索引项的访问判断是否需要拉取下一页，手动遍历所有已加载项、一次性插入所有粘滞头部和内容项的写法，会让Paging无法正确感知触底阈值，因此仅加载2页就停止发起请求。
• 调用invalidateNotifications()会直接销毁当前PagingSource实例、清空所有已加载的分页缓存，本质是全量重载列表，天然无法保留原有滚动位置；加上原有写法中粘滞头部项没有设置唯一稳定key，LazyColumn无法正确计算滚动偏移，哪怕手动调用滚动方法也无法准确定位。

修复方案1：解决分页加载中断问题 #

不要在UI层对已加载的分页数据做分组处理，改用Paging官方提供的insertSeparators扩展在数据流层面插入粘滞头部项，完全保留Paging的懒加载触底逻辑。

1. 首先定义密封类统一承载列表两种项类型：

sealed interface NotificationListItem {
    data class Header(val label: String) : NotificationListItem
    data class Content(val data: NotificationCenterMessage) : NotificationListItem
}

2. 修改分页数据流的转换逻辑，在流中插入头部分隔项：

override fun loadNotifications(): Flow<PagingData<NotificationListItem>> {
    return Pager(
        config = PagingConfig(
            pageSize = 30,
            enablePlaceholders = false,
            initialLoadSize = 90 // 和默认首屏3页加载量一致，保证滚动位置恢复
        ),
        pagingSourceFactory = invalidatingFactory
    ).flow
        .map { pagingData ->
            // 先将原始通知项包装为Content类型
            pagingData.map { NotificationListItem.Content(it) as NotificationListItem }
        }
        .insertSeparators { beforeItem, afterItem ->
            // 对比前后项的分组标识，判断是否需要插入头部
            val afterContent = afterItem as? NotificationListItem.Content ?: return@insertSeparators null
            val beforeGroup = (beforeItem as? NotificationListItem.Content)?.data?.let { extractNotificationHeader(it) }
            val currentGroup = extractNotificationHeader(afterContent.data)
            if (beforeGroup != currentGroup) {
                NotificationListItem.Header(currentGroup)
            } else {
                null
            }
        }
}

3. 修改LazyColumn实现，按索引访问分页项自动触发加载，给所有项设置唯一稳定key：

val listState = rememberLazyListState()
val notifications = viewModel.notifications.collectAsLazyPagingItems()

LazyColumn(
    modifier = modifier.fillMaxSize(),
    contentPadding = PaddingValues(20.dp),
    horizontalAlignment = Alignment.CenterHorizontally,
    state = listState
) {
    val itemCount = notifications.itemCount
    (0 until itemCount).forEach { index ->
        when (val item = notifications[index]) { // 访问索引时自动触发分页加载判断
            is NotificationListItem.Header -> {
                stickyHeader(key = "header_${item.label}") {
                    NotificationHeader(
                        modifier = Modifier.fillMaxWidth(),
                        value = item.label
                    )
                }
            }
            is NotificationListItem.Content -> {
                item(key = item.data.notificationId) {
                    NotificationMessage(
                        notification = item.data,
                        onNotificationClick = { onNotificationClick(item.data) }
                    )
                }
            }
            null -> {} // 占位项空处理即可
        }
    }
}

修复方案2：解决刷新丢失滚动位置问题 #

不要用invalidateNotifications()处理单条通知已读状态更新，invalidate是全量刷新场景用的API，局部状态更新用Paging的原地更新能力即可，完全不会重载列表、自然不会丢失滚动位置：

// 标记通知已读的逻辑，写在ViewModel中
fun markNotificationRead(targetId: String) {
    viewModelScope.launch {
        notificationFlow.updateData { currentList ->
            currentList.map { item ->
                if (item is NotificationListItem.Content && item.data.notificationId == targetId) {
                    item.copy(data = item.data.copy(isRead = true)) // 替换为你自己的已读状态字段
                } else {
                    item
                }
            }
        }
    }
}

如果确实需要触发全量刷新（比如下拉刷新场景），只要保证所有列表项（包括粘滞头部）都设置了唯一稳定key，Paging 3.0+版本会自动在刷新后恢复原有滚动位置，不需要手动调用animateScrollToItem()。

内容的提问来源于stack exchange，提问作者Hadi Ahmed