当内容高度和视窗高度比较接近的时候，上滑list会触发Flatlist自身的上拉效果，header不跟手。
以下来自AI的分析：
在 Android 上，@sdcx/nested-scroll 通过 Android 的 NestedScrolling API 与内部 FlatList（底层是 RecyclerView）协同。FlatList 触发 dispatchNestedPreScroll() 把滚动事件抛给父级 NestedScrollView 让 header 滚出去。
但 RecyclerView 有个行为：
contentSize > 自身高度：RecyclerView 认为自己可滚动 → 调用 dispatchNestedPreScroll() → 父级吸顶 ✅
contentSize ≈ viewport（接近但小于）：RecyclerView 认为自己理论上能参与嵌套滚动，但实际没有可滚动距离 → 它会"消化"掉触摸事件但不抛给父级 → 卡住 ❌
contentSize << viewport（远小于，比如1条数据）：FlatList 太短了，用户触摸的位置可能直接落在 FlatList 下方的空白区域，或者 FlatList 干脆没参与嵌套滚动协议 → 父级 NestedScrollView 直接处理滚动 → 看起来"吸顶正常"，但其实是整个 NestedScrollView 在滚动（不是真的嵌套）✅
当内容高度和视窗高度比较接近的时候，上滑list会触发Flatlist自身的上拉效果，header不跟手。
以下来自AI的分析：
在 Android 上，@sdcx/nested-scroll 通过 Android 的 NestedScrolling API 与内部 FlatList（底层是 RecyclerView）协同。FlatList 触发 dispatchNestedPreScroll() 把滚动事件抛给父级 NestedScrollView 让 header 滚出去。
但 RecyclerView 有个行为：
contentSize > 自身高度：RecyclerView 认为自己可滚动 → 调用 dispatchNestedPreScroll() → 父级吸顶 ✅
contentSize ≈ viewport（接近但小于）：RecyclerView 认为自己理论上能参与嵌套滚动，但实际没有可滚动距离 → 它会"消化"掉触摸事件但不抛给父级 → 卡住 ❌
contentSize << viewport（远小于，比如1条数据）：FlatList 太短了，用户触摸的位置可能直接落在 FlatList 下方的空白区域，或者 FlatList 干脆没参与嵌套滚动协议 → 父级 NestedScrollView 直接处理滚动 → 看起来"吸顶正常"，但其实是整个 NestedScrollView 在滚动（不是真的嵌套）✅