现在碰上个新需求，A是个虚拟列表，B也是个虚拟列表，A下有N个节点，大小各不相同，B也是其中一个，A和B的滚动方向是一样的，需求是滚动的时候，滚到B的时候，如果B的大小大于A的视图，B铺满A以后，优先滚动B，B的数据滚动完成以后，在滚动A，如果B的视图没那么大，则直接滚A ,哪位大佬的支持这个，直接贴商城store~
这种特殊需求感觉只能自己写
拿现成的虚拟列表，让AI改就行，你都能说清楚需求，用GPT3 codex就能生成出来
不是没让ai调教哦，cursor 生成的也有问题，滚动衔接不行，按着不松手拖动有问题，滑动看着还算正常~
这个需求代价太高，没有人会为了这个特殊需求实现一个特殊虚拟列表了，而且感觉这已经不是虚拟列表的范畴了，这是业务层干的事。
最优解是打死策划
B 的内容放到A就好了，为什么要嵌套一个 B？让A支持不同尺寸子节点。
嵌套循环还是很常见的。。
因为现在的应用场景就是这样的。。没办法。。
怎么没办法？你放A里面，效果一样啊，没看出有什么区别
参考一下这个？
1赞
好的，我去看一下，感谢