嗯这句话几乎原样出现在我们项目的群里。产品经理指着设计稿上那个滚轮选择器ScrollWheel问我这里面的卡片有的是一行文字有的是两行文字加一张小图能不能直接放进同一个滚轮里我第一反应是能啊给每个组件设置不同的高度不就行了。然后我就收获了一堆奇奇怪怪的 Bug文字重叠、滚动位置错乱、点击命中不准。这篇文章就把这个问题的完整链路写清楚为什么滚轮组件天然排斥不同高度的子项、实测会踩到哪些坑、几种可行的破解方案、不同框架下的落地代码以及我最后在项目里到底怎么选的。1. 滚轮组件默认只认等高子项问题并非你的错觉1.1 一个看似简单却反直觉的需求先还原一下需求。我们当时做的是一个“目标设定”页面用户需要在一个类似飞盘转轮的滚轮里选择“每周阅读时长”“每周运动次数”这类选项。大部分选项只有一行字但其中有一个选项需要附上说明文字还有一个小图标。设计稿上它比别的选项高出一截。在我接手之前大家的想法都很一致ScrollWheel 既然是滚轮那就是一个竖向滚动的容器里面放多个组件天然应该支持不同高度。但实际一跑所有的组件都被压成了同一个高度有的内容被截断了有的周围出现了一大片空白。这不是我们代码写错了而是滚轮组件的基本运行逻辑决定的。1.2 滚轮的底层布局假设所有子项共享同一个高度绝大多数滚轮组件不管叫什么名字底层布局模型都遵循一个极简规则把内容区当成一条“传送带”每一项占用的高度是同一个固定值滚轮的位置通过“索引 × 固定高度”计算出来。举个例子。iOS 里 UIPickerView 的rowHeight就是全局设定的同一时间所有行都遵守这个高度。Flutter 里ListWheelScrollView的itemExtent也是整个列表统一的单位长度。Web 端常见的 picker 类组件更是直接把 item 高度写成了一个常量比如 32px 或者 40px。为什么要这么设计因为它让整个布局计算变得极其简单滚动偏移量可以直接用索引算出来不需要实时测量每一个子项滚轮运动过程中的放大缩小效果强烈依赖“中心位置”概念中心位置如果用统一高度计算一帧之内就能完成命中测试也简单比如当前显示的五个 item哪个在中间只需要计算偏移量落在哪个区间即可。一旦打破“所有子项等高”这个假设上面这套计算全部要重写每个子项的位置变成累加高度滚动到中间时该对齐哪个点的语义变得模糊点击命中测试也必须根据每个子项实际坐标来算。这不是改一个参数就能解决的问题而是改变整个布局模型的问题。想清楚这一点就明白“Cant the ScrollWheel set components of different heights”这句疑问答案不是“不能”而是“默认模型不支持需要换一种实现思路”。2. 实测第一版不同高度组件在滚轮里的真实表现2.1 现象清单比你想的更离谱知道原理是一回事实际踩坑又是一回事。我在当时直接做了一个最小 demo强制给滚轮里的某个组件设置了不同高度的 frame。结果是这样的高度被视觉压缩。滚轮为了维持“每个 item 占位一致”会把所有内容强制放进同一个矩形区域高组件的内容被压扁或裁掉。文本重叠。低组件和高组件相邻时高组件的下半部分会叠到下一个 item 的绘制区域里视觉上直接乱掉。滚动停止位置错乱。滚轮在惯性滚动结束后会找一个“稳定点”稳定点的计算以统一高度为周期。如果某个 item 实际高度是其他 item 的两倍滚轮停下来的位置经常是两个 item 的交界处没有一个 item 真正居中。点击命中不准。用户明明点的是第三个 item命中测试却命中了第二个因为命中区域还是按统一高度算的。这些现象单独出现还能忍一起出现的时候基本就属于“功能不可用”。我自己的测试结论是在不修改布局模型的前提下试图通过“直接改高度”让滚轮支持不同高度的组件是一条死路。2.2 根因追踪三处计算都建立在“假高度”上我把问题拆了一遍发现滚轮组件里有三处硬编码的高度假设。只要有一个子项高度不同三处全崩。第一处是偏移量换算。滚轮组件维护一个当前偏移量然后靠“偏移量 / 固定高度”反推出当前中心索引。当固定高度是个假高度时索引和内容的对齐关系就错了。比如第五个 item 实际位置在 200 像素处而组件以为它在 180 像素处滚动就会错位。第二处是视觉变换。滚轮效果通常会给每个 item 加上缩放、倾斜、透明度越远离中心越小越淡。这个效果的强弱依赖 item 到中心的距离而距离的计算又依赖统一高度。如果 item 高度不一致离中心同样像素距离的两个 item视觉上放大倍率却完全不同看起来就像在抖动。第三处是 hit test。滚轮组件会根据每个 item 的相对位置计算点击区域计算逻辑通常是从中心开始上下等距划分。高度不一致后这个等距划分的区域与真实渲染区域不重合点击自然不准。这三处问题不是靠样式 hack 能解决的必须从根源上改变布局模型。所以后文讲的几种方案本质上都是在“绕开默认布局模型”。3. 破解思路等高网格化、动态测量、切换容器三选一3.1 方案一等高网格化——把不同内容塞进同一个固定高度这个方法最省事思路是“强迫每个 item 在滚轮里占同一个高度但内容在 item 内部自由布局”。比如统一高度设为 88 像素一行文字的 item 就在垂直方向居中显示两行文字加一张小图的 item 也在 88 像素内部排列内容。优点很明显完全不需要改滚轮组件的布局逻辑所有默认效果都还在改动量小稳定性高。缺点也同样明显会出现大量空白尤其是内容很少的 item 占着很高的位置视觉密度不均匀。它适合什么场景呢选项数量不多内容差异不大且 UI 对间距容忍度较高的页面。比如设置页里的滚轮选择器选项都是“低/中/高”这种差异化小时可以用。但如果设计稿明确要求不同 item 高度直接不同比如有的是卡片、有的是文字条目这个方法就会被毙掉因为空白太扎眼。我当时的最初版就是用的这个方案顺利上线但产品反馈“看起来每个格子都太大”于是才被迫想后面的方案。3.2 方案二动态测量——让每个 item 获得真实尺寸动态测量的逻辑比较直白在把 item 放进滚轮之前先测量内容得到真实高度然后把高度传给滚轮布局系统。听起来完美但有一个前提滚轮布局系统必须支持“每个 item 单独设置尺寸”。如果用的是 UIPickerView 或ListWheelScrollView这种写死itemExtent的组件连传不同高度的入口都没有那动态测量就只能搭配“自定义滚轮布局”使用。自定义滚轮怎么做核心是把原来一步到位的布局拆成两步第一步计算每个 item 的高度。可以提前测量也可以在 item 渲染完成后通过回调拿到实际高度再刷新布局。第二步自己维护一个内容总高度和一个累积偏移表。任何位置计算都不再使用“索引 × 固定高度”而是先遍历累积偏移表找到当前偏移量对应的是哪个 item以及 item 内部的相对偏移位置。滚动效果也要自己处理每个 item 到中心的距离需要基于 item 真实位置减去当前偏移量来计算再根据距离做缩放和透明度的动画。这套方案能做到视觉上的完美适配但工程量不小。它适合 item 内容差异大、数量不多比如少于 10 个、且交互要求接近原生滚轮的场景。如果内容数量很多动态测量加自定义布局的计算量会明显上升后面性能篇会细说。3.3 方案三切换容器——不再用滚轮而是用普通列表加居中高亮很多场景下用户真正需要的并不是“滚轮的 3D 旋转效果”而是“上下滑动选择当前选中的项高亮”。既然滚轮对等高有硬性要求那就干脆换成普通列表。普通列表天然支持不同高度的子项因为它的布局模型本身就是线性的每个子项用自己的实际 frame。然后只需要在列表中间画一条高亮分隔线或者给当前居中的 item 加一个放大效果用户照样能感知到“正在选择哪一项”。这个方案的优点是实现简单、支持任意高度、性能稳定、后续要加多行文本或复杂卡片都没问题。缺点也很现实失去了滚轮那种“两边逐渐缩小消失”的酷炫效果产品上如果很看重这个视觉特征就得做取舍。我在后面的落地代码里会展示这个方案的一个具体形态它是我最终选型的基础。4. 不同框架的落地代码参考4.1 Flutter从 ListWheelScrollView 迁移到居中列表Flutter 里ListWheelScrollView是标准的滚轮组件它的itemExtent必须固定。如果非要支持不同高度一种替代方案是自己写 Linear 列表 滚动定位。可以先定义一个控制器监听滚动偏移量实时计算当前中心项索引然后对中间项做放大和透明度的处理class CenterListPage extends StatefulWidget { const CenterListPage({super.key}); override StateCenterListPage createState() _CenterListPageState(); } class _CenterListPageState extends StateCenterListPage { final ScrollController _controller ScrollController(); final Listdouble _itemHeights [56, 88, 56, 120, 56, 72]; override Widget build(BuildContext context) { return Stack( children: [ ListView.builder( controller: _controller, itemCount: _itemHeights.length, itemBuilder: (context, index) { return Container( height: _itemHeights[index], alignment: Alignment.center, decoration: BoxDecoration( color: index.isEven ? Colors.blueGrey : Colors.blueGrey[100], ), child: Text(选项 ${index 1}), ); }, ), Center( child: Container( height: 2, color: Colors.orange, ), ), ], ); } }这个例子用了一个_itemHeights数组来模拟不同高度实际项目中这个数组应该来自对内容测量后的真实结果。ListView.builder 支持每个 item 不同高度代码核心就这么简单一个普通列表加上一条居中指示线。如果想保留滚轮的“中间放大”感觉可以在滚动回调中根据 item 到中心的像素距离修改 item 的 scale_controller.addListener(() { final offset _controller.offset; for (int i 0; i _itemHeights.length; i) { final itemCenter _getItemCenter(i) - offset; final distance (itemCenter - screenCenter).abs(); final scale (1 - distance / 400).clamp(0.7, 1.0); // 根据 index 用 GlobalKey 找到对应 item更新 scale } });需要注意Flutter 里ListView的 item 并不保证在所有帧都能拿到自己的 RenderObject如果 item 滑出屏幕再通过 GlobalKey 找就可能为空。所以不要在每个滚动帧里做强依赖只做视觉比例更新或者用AnimatedScale配合索引变化来控制。4.2 SwiftUI用 ScrollView 加 scrollTargetBehavior 解决SwiftUI 里以前做滚轮选择器普遍用UIPickerView包装实际还是固定高度模型。iOS 17 之后有了scrollTargetBehavior配合 fixedSize 可以实现类似“滚轮吸附”的效果而且 item 高度可以不同。基本思路是普通 ScrollView每个子项设置自己的高度滚动行为用.scrollTargetBehavior(.viewAligned)让列表在停止时自动对齐到最近的子项ScrollView { LazyVStack(spacing: 8) { ForEach(items) { item in Text(item.title) .padding() .frame(height: item.height) .scrollTargetLayout() } } } .scrollTargetBehavior(.viewAligned) .frame(height: 300)这里面有两个关键点。第一scrollTargetLayout()要加在子项的公共容器上让滚动系统知道对齐的目标是哪个区域。第二frame(height:)按 item 自己的数据设置不再使用 UIPickerView 那种固定行高。如果项目还停留在低版本 iOS可以用onChange(of: scrollPosition)监听滚动偏移手动计算当前中心 item然后把居中 item 做放大处理。但需要知道手动方案里 item 的真实 y 坐标也要自己维护等于把动态测量那套逻辑在 SwiftUI 里再实现一遍。我建议能用新 API 就用新 API省心很多。4.3 Web 前端CSS scroll-snap 一行解决Web 端做不同高度的滚轮选择器最简单的方式是 CSSscroll-snap-type它允许每个子项有自己的高度同时保持滚动吸附的交互。HTML 结构大致如下div classwheel styleheight: 240px; overflow-y: scroll; scroll-snap-type: y proximity; div classitem styleheight: 56px;选项 A/div div classitem styleheight: 120px; 选项 Bbr/包含两行说明文字 /div div classitem styleheight: 72px;选项 C/div /divCSS 部分.wheel { scroll-snap-type: y proximity; } .wheel .item { scroll-snap-align: center; }scroll-snap-align: center保证了每次滚动停止时子项尽量对准滚动容器的中间位置。不同 item 的高度可以任意设置浏览器会自动计算对齐位置。这个方案比 JS 定义滚轮组件省力得多而且在移动端和桌面端现代浏览器上支持稳定。唯一的痛点是“惯性滚动的力度不好控制”有的浏览器滚动停止位置距离预期较远还是需要一点滚动力度补偿逻辑但绝大多数情况下够用。5. 团队项目里的避坑清单与性能底线5.1 测量结果一定要缓存不管是动态测量还是普通列表方案都要面对“高度从哪来”的问题。很多人会直接在build方法里实时测量结果每次滚动都触发一轮文本尺寸计算列表一长就掉帧。正确做法是把测量结果放进一个缓存字典键是 item 的唯一标识值是高度。只在 item 内容变化时重新测量。如果是图片异步加载导致的尺寸变化等图片加载完成后再更新对应高度并主动刷新那一个 item而不是刷新整个列表。我这里有一个常见的反面案例列表有 30 个 item每个都包含不等长的文字和一张图片图片尺寸又不一样。直接实时测量时每次滚动都卡卡到明显掉帧。加了缓存并只在图片加载完成后更新对应行的高度后滚动的流畅度恢复到接近原生。5.2 滚动过程中的跳动问题用普通列表模拟滚轮时最容易被忽视的问题是“滚动操作中更新 item 高度”。如果用户正在快速滑动某个 item 因为图片加载完毕而突然变高整个列表内容高度变化滚动位置就会瞬间跳动视觉上像页面闪了一下。处理思路有两个方向。一是延迟更新图片加载完成后不直接改高度而是等页面静置超过 300ms 后再更新。这样用户滑动过程中不会被打断。二是保留旧高度如果新旧高度差距不大可以简单保留旧值等下次布局时再改。大多数场景都不需要像素级精确体验优先。我自己偏向用“延迟更新”方案因为它不需要处理复杂的状态同步实现起来最直接。5.3 底部留白与惯性边界普通滚轮的惯性结束位置通常会被组件自己纠正到最近的一个 item 中心点。但普通列表的惯性是自由滚动最后可能停在任意位置比如停在两个 item 的交界处或者最后几个 item 上方还露出很大空白。解决底部空白的方法是给列表内容底部补一段 padding让最后一个 item 也能滚到中心位置。具体数值大约是容器高度的一半减去最后一个 item 高度的一半。同理顶部也要补一段否则第一个 item 会顶在容器顶部无法居中。如果要实现“自动吸附到最近 item”需要监听滚动结束事件用animateTo把偏移量移到目标 item 的中心位置。这一步在 Web 端可以直接用 scroll-snap在原生端就手动处理代码量不大但很关键否则用户会觉得这个“滚轮”手感怪怪的。5.4 命中测试与无障碍动态测量方案里自定义命中测试不要自己实现直接用组件系统给出的 hitTest 结果前提是 item 的真实 frame 已更新。普通列表方案则天然命中正确因为每个 item 的 frame 就是实际 frame。无障碍也要注意滚轮组件一般会给辅助功能标记一个“可调节值”但不同 item 高度下辅助功能可能读不出当前选中的是哪一项。在普通列表方案里最好手动设置 accessibility 的 value值就是当前高亮的 item 文本。6. 我最终的选型建议和实际心得折腾完这一轮我给团队写了一个选型判断表按需求强度来推荐方案。需求特征推荐方案原因选项内容长度差异小UI 允许大量留白等高网格化改动最小、稳定性最高选项内容差异大但数量少10 个动态测量 自定义滚轮视觉最贴近滚轮效果选项内容差异大数量可能很多普通列表 居中高亮性能最稳支持任意高度Web 端移动端兼容为主CSS scroll-snap一行代码解决吸附只想要“能展示不同高度”且不要求 3D 滚轮效果普通列表 高亮线最省事接受度最高我最终在项目里选的是普通列表加居中高亮。原因很简单选项里有两行文字和图片高度差异大而且列表整体不超过 8 个 item不需要 3D 旋转来节省空间。用户实际感知上“中间有一条高亮线”和“滚轮停到中间”的区别非常小但维护成本差很多。回头看这个问题的本质ScrollWheel 的等高设计是为了用空间换取计算效率。而产品需求是变化的内容永远往更多样化的方向走。所以与其纠结“怎么让滚轮支持不同高度”不如想清楚“滚轮效果是不是这个页面必需的”。很多时候用户需要的只是一个能上下滑动、当前项清晰可见的选择控件而不是一个严格意义上的转盘。如果哪天产品经理说你一定要保留 3D 滚轮效果那再去自定义布局也不迟——但请做好连续调参的准备缩放比例、透明度渐变、远处 item 的最小尺寸每一个参数在高矮混合的列表里都要重新校准。这一步没有捷径只能拿真机反复试。最后再分享一个小技巧无论用哪种方案一开始就做一个“高度差异化调试页”把所有极端情况最长文本、最短文本、带图片、超长说明塞进去跑一遍。等上线后才发现某个特殊内容导致滚动跳位那就真的晚了。
滚轮组件如何支持不同高度子项：方案对比与工程实践
嗯这句话几乎原样出现在我们项目的群里。产品经理指着设计稿上那个滚轮选择器ScrollWheel问我这里面的卡片有的是一行文字有的是两行文字加一张小图能不能直接放进同一个滚轮里我第一反应是能啊给每个组件设置不同的高度不就行了。然后我就收获了一堆奇奇怪怪的 Bug文字重叠、滚动位置错乱、点击命中不准。这篇文章就把这个问题的完整链路写清楚为什么滚轮组件天然排斥不同高度的子项、实测会踩到哪些坑、几种可行的破解方案、不同框架下的落地代码以及我最后在项目里到底怎么选的。1. 滚轮组件默认只认等高子项问题并非你的错觉1.1 一个看似简单却反直觉的需求先还原一下需求。我们当时做的是一个“目标设定”页面用户需要在一个类似飞盘转轮的滚轮里选择“每周阅读时长”“每周运动次数”这类选项。大部分选项只有一行字但其中有一个选项需要附上说明文字还有一个小图标。设计稿上它比别的选项高出一截。在我接手之前大家的想法都很一致ScrollWheel 既然是滚轮那就是一个竖向滚动的容器里面放多个组件天然应该支持不同高度。但实际一跑所有的组件都被压成了同一个高度有的内容被截断了有的周围出现了一大片空白。这不是我们代码写错了而是滚轮组件的基本运行逻辑决定的。1.2 滚轮的底层布局假设所有子项共享同一个高度绝大多数滚轮组件不管叫什么名字底层布局模型都遵循一个极简规则把内容区当成一条“传送带”每一项占用的高度是同一个固定值滚轮的位置通过“索引 × 固定高度”计算出来。举个例子。iOS 里 UIPickerView 的rowHeight就是全局设定的同一时间所有行都遵守这个高度。Flutter 里ListWheelScrollView的itemExtent也是整个列表统一的单位长度。Web 端常见的 picker 类组件更是直接把 item 高度写成了一个常量比如 32px 或者 40px。为什么要这么设计因为它让整个布局计算变得极其简单滚动偏移量可以直接用索引算出来不需要实时测量每一个子项滚轮运动过程中的放大缩小效果强烈依赖“中心位置”概念中心位置如果用统一高度计算一帧之内就能完成命中测试也简单比如当前显示的五个 item哪个在中间只需要计算偏移量落在哪个区间即可。一旦打破“所有子项等高”这个假设上面这套计算全部要重写每个子项的位置变成累加高度滚动到中间时该对齐哪个点的语义变得模糊点击命中测试也必须根据每个子项实际坐标来算。这不是改一个参数就能解决的问题而是改变整个布局模型的问题。想清楚这一点就明白“Cant the ScrollWheel set components of different heights”这句疑问答案不是“不能”而是“默认模型不支持需要换一种实现思路”。2. 实测第一版不同高度组件在滚轮里的真实表现2.1 现象清单比你想的更离谱知道原理是一回事实际踩坑又是一回事。我在当时直接做了一个最小 demo强制给滚轮里的某个组件设置了不同高度的 frame。结果是这样的高度被视觉压缩。滚轮为了维持“每个 item 占位一致”会把所有内容强制放进同一个矩形区域高组件的内容被压扁或裁掉。文本重叠。低组件和高组件相邻时高组件的下半部分会叠到下一个 item 的绘制区域里视觉上直接乱掉。滚动停止位置错乱。滚轮在惯性滚动结束后会找一个“稳定点”稳定点的计算以统一高度为周期。如果某个 item 实际高度是其他 item 的两倍滚轮停下来的位置经常是两个 item 的交界处没有一个 item 真正居中。点击命中不准。用户明明点的是第三个 item命中测试却命中了第二个因为命中区域还是按统一高度算的。这些现象单独出现还能忍一起出现的时候基本就属于“功能不可用”。我自己的测试结论是在不修改布局模型的前提下试图通过“直接改高度”让滚轮支持不同高度的组件是一条死路。2.2 根因追踪三处计算都建立在“假高度”上我把问题拆了一遍发现滚轮组件里有三处硬编码的高度假设。只要有一个子项高度不同三处全崩。第一处是偏移量换算。滚轮组件维护一个当前偏移量然后靠“偏移量 / 固定高度”反推出当前中心索引。当固定高度是个假高度时索引和内容的对齐关系就错了。比如第五个 item 实际位置在 200 像素处而组件以为它在 180 像素处滚动就会错位。第二处是视觉变换。滚轮效果通常会给每个 item 加上缩放、倾斜、透明度越远离中心越小越淡。这个效果的强弱依赖 item 到中心的距离而距离的计算又依赖统一高度。如果 item 高度不一致离中心同样像素距离的两个 item视觉上放大倍率却完全不同看起来就像在抖动。第三处是 hit test。滚轮组件会根据每个 item 的相对位置计算点击区域计算逻辑通常是从中心开始上下等距划分。高度不一致后这个等距划分的区域与真实渲染区域不重合点击自然不准。这三处问题不是靠样式 hack 能解决的必须从根源上改变布局模型。所以后文讲的几种方案本质上都是在“绕开默认布局模型”。3. 破解思路等高网格化、动态测量、切换容器三选一3.1 方案一等高网格化——把不同内容塞进同一个固定高度这个方法最省事思路是“强迫每个 item 在滚轮里占同一个高度但内容在 item 内部自由布局”。比如统一高度设为 88 像素一行文字的 item 就在垂直方向居中显示两行文字加一张小图的 item 也在 88 像素内部排列内容。优点很明显完全不需要改滚轮组件的布局逻辑所有默认效果都还在改动量小稳定性高。缺点也同样明显会出现大量空白尤其是内容很少的 item 占着很高的位置视觉密度不均匀。它适合什么场景呢选项数量不多内容差异不大且 UI 对间距容忍度较高的页面。比如设置页里的滚轮选择器选项都是“低/中/高”这种差异化小时可以用。但如果设计稿明确要求不同 item 高度直接不同比如有的是卡片、有的是文字条目这个方法就会被毙掉因为空白太扎眼。我当时的最初版就是用的这个方案顺利上线但产品反馈“看起来每个格子都太大”于是才被迫想后面的方案。3.2 方案二动态测量——让每个 item 获得真实尺寸动态测量的逻辑比较直白在把 item 放进滚轮之前先测量内容得到真实高度然后把高度传给滚轮布局系统。听起来完美但有一个前提滚轮布局系统必须支持“每个 item 单独设置尺寸”。如果用的是 UIPickerView 或ListWheelScrollView这种写死itemExtent的组件连传不同高度的入口都没有那动态测量就只能搭配“自定义滚轮布局”使用。自定义滚轮怎么做核心是把原来一步到位的布局拆成两步第一步计算每个 item 的高度。可以提前测量也可以在 item 渲染完成后通过回调拿到实际高度再刷新布局。第二步自己维护一个内容总高度和一个累积偏移表。任何位置计算都不再使用“索引 × 固定高度”而是先遍历累积偏移表找到当前偏移量对应的是哪个 item以及 item 内部的相对偏移位置。滚动效果也要自己处理每个 item 到中心的距离需要基于 item 真实位置减去当前偏移量来计算再根据距离做缩放和透明度的动画。这套方案能做到视觉上的完美适配但工程量不小。它适合 item 内容差异大、数量不多比如少于 10 个、且交互要求接近原生滚轮的场景。如果内容数量很多动态测量加自定义布局的计算量会明显上升后面性能篇会细说。3.3 方案三切换容器——不再用滚轮而是用普通列表加居中高亮很多场景下用户真正需要的并不是“滚轮的 3D 旋转效果”而是“上下滑动选择当前选中的项高亮”。既然滚轮对等高有硬性要求那就干脆换成普通列表。普通列表天然支持不同高度的子项因为它的布局模型本身就是线性的每个子项用自己的实际 frame。然后只需要在列表中间画一条高亮分隔线或者给当前居中的 item 加一个放大效果用户照样能感知到“正在选择哪一项”。这个方案的优点是实现简单、支持任意高度、性能稳定、后续要加多行文本或复杂卡片都没问题。缺点也很现实失去了滚轮那种“两边逐渐缩小消失”的酷炫效果产品上如果很看重这个视觉特征就得做取舍。我在后面的落地代码里会展示这个方案的一个具体形态它是我最终选型的基础。4. 不同框架的落地代码参考4.1 Flutter从 ListWheelScrollView 迁移到居中列表Flutter 里ListWheelScrollView是标准的滚轮组件它的itemExtent必须固定。如果非要支持不同高度一种替代方案是自己写 Linear 列表 滚动定位。可以先定义一个控制器监听滚动偏移量实时计算当前中心项索引然后对中间项做放大和透明度的处理class CenterListPage extends StatefulWidget { const CenterListPage({super.key}); override StateCenterListPage createState() _CenterListPageState(); } class _CenterListPageState extends StateCenterListPage { final ScrollController _controller ScrollController(); final Listdouble _itemHeights [56, 88, 56, 120, 56, 72]; override Widget build(BuildContext context) { return Stack( children: [ ListView.builder( controller: _controller, itemCount: _itemHeights.length, itemBuilder: (context, index) { return Container( height: _itemHeights[index], alignment: Alignment.center, decoration: BoxDecoration( color: index.isEven ? Colors.blueGrey : Colors.blueGrey[100], ), child: Text(选项 ${index 1}), ); }, ), Center( child: Container( height: 2, color: Colors.orange, ), ), ], ); } }这个例子用了一个_itemHeights数组来模拟不同高度实际项目中这个数组应该来自对内容测量后的真实结果。ListView.builder 支持每个 item 不同高度代码核心就这么简单一个普通列表加上一条居中指示线。如果想保留滚轮的“中间放大”感觉可以在滚动回调中根据 item 到中心的像素距离修改 item 的 scale_controller.addListener(() { final offset _controller.offset; for (int i 0; i _itemHeights.length; i) { final itemCenter _getItemCenter(i) - offset; final distance (itemCenter - screenCenter).abs(); final scale (1 - distance / 400).clamp(0.7, 1.0); // 根据 index 用 GlobalKey 找到对应 item更新 scale } });需要注意Flutter 里ListView的 item 并不保证在所有帧都能拿到自己的 RenderObject如果 item 滑出屏幕再通过 GlobalKey 找就可能为空。所以不要在每个滚动帧里做强依赖只做视觉比例更新或者用AnimatedScale配合索引变化来控制。4.2 SwiftUI用 ScrollView 加 scrollTargetBehavior 解决SwiftUI 里以前做滚轮选择器普遍用UIPickerView包装实际还是固定高度模型。iOS 17 之后有了scrollTargetBehavior配合 fixedSize 可以实现类似“滚轮吸附”的效果而且 item 高度可以不同。基本思路是普通 ScrollView每个子项设置自己的高度滚动行为用.scrollTargetBehavior(.viewAligned)让列表在停止时自动对齐到最近的子项ScrollView { LazyVStack(spacing: 8) { ForEach(items) { item in Text(item.title) .padding() .frame(height: item.height) .scrollTargetLayout() } } } .scrollTargetBehavior(.viewAligned) .frame(height: 300)这里面有两个关键点。第一scrollTargetLayout()要加在子项的公共容器上让滚动系统知道对齐的目标是哪个区域。第二frame(height:)按 item 自己的数据设置不再使用 UIPickerView 那种固定行高。如果项目还停留在低版本 iOS可以用onChange(of: scrollPosition)监听滚动偏移手动计算当前中心 item然后把居中 item 做放大处理。但需要知道手动方案里 item 的真实 y 坐标也要自己维护等于把动态测量那套逻辑在 SwiftUI 里再实现一遍。我建议能用新 API 就用新 API省心很多。4.3 Web 前端CSS scroll-snap 一行解决Web 端做不同高度的滚轮选择器最简单的方式是 CSSscroll-snap-type它允许每个子项有自己的高度同时保持滚动吸附的交互。HTML 结构大致如下div classwheel styleheight: 240px; overflow-y: scroll; scroll-snap-type: y proximity; div classitem styleheight: 56px;选项 A/div div classitem styleheight: 120px; 选项 Bbr/包含两行说明文字 /div div classitem styleheight: 72px;选项 C/div /divCSS 部分.wheel { scroll-snap-type: y proximity; } .wheel .item { scroll-snap-align: center; }scroll-snap-align: center保证了每次滚动停止时子项尽量对准滚动容器的中间位置。不同 item 的高度可以任意设置浏览器会自动计算对齐位置。这个方案比 JS 定义滚轮组件省力得多而且在移动端和桌面端现代浏览器上支持稳定。唯一的痛点是“惯性滚动的力度不好控制”有的浏览器滚动停止位置距离预期较远还是需要一点滚动力度补偿逻辑但绝大多数情况下够用。5. 团队项目里的避坑清单与性能底线5.1 测量结果一定要缓存不管是动态测量还是普通列表方案都要面对“高度从哪来”的问题。很多人会直接在build方法里实时测量结果每次滚动都触发一轮文本尺寸计算列表一长就掉帧。正确做法是把测量结果放进一个缓存字典键是 item 的唯一标识值是高度。只在 item 内容变化时重新测量。如果是图片异步加载导致的尺寸变化等图片加载完成后再更新对应高度并主动刷新那一个 item而不是刷新整个列表。我这里有一个常见的反面案例列表有 30 个 item每个都包含不等长的文字和一张图片图片尺寸又不一样。直接实时测量时每次滚动都卡卡到明显掉帧。加了缓存并只在图片加载完成后更新对应行的高度后滚动的流畅度恢复到接近原生。5.2 滚动过程中的跳动问题用普通列表模拟滚轮时最容易被忽视的问题是“滚动操作中更新 item 高度”。如果用户正在快速滑动某个 item 因为图片加载完毕而突然变高整个列表内容高度变化滚动位置就会瞬间跳动视觉上像页面闪了一下。处理思路有两个方向。一是延迟更新图片加载完成后不直接改高度而是等页面静置超过 300ms 后再更新。这样用户滑动过程中不会被打断。二是保留旧高度如果新旧高度差距不大可以简单保留旧值等下次布局时再改。大多数场景都不需要像素级精确体验优先。我自己偏向用“延迟更新”方案因为它不需要处理复杂的状态同步实现起来最直接。5.3 底部留白与惯性边界普通滚轮的惯性结束位置通常会被组件自己纠正到最近的一个 item 中心点。但普通列表的惯性是自由滚动最后可能停在任意位置比如停在两个 item 的交界处或者最后几个 item 上方还露出很大空白。解决底部空白的方法是给列表内容底部补一段 padding让最后一个 item 也能滚到中心位置。具体数值大约是容器高度的一半减去最后一个 item 高度的一半。同理顶部也要补一段否则第一个 item 会顶在容器顶部无法居中。如果要实现“自动吸附到最近 item”需要监听滚动结束事件用animateTo把偏移量移到目标 item 的中心位置。这一步在 Web 端可以直接用 scroll-snap在原生端就手动处理代码量不大但很关键否则用户会觉得这个“滚轮”手感怪怪的。5.4 命中测试与无障碍动态测量方案里自定义命中测试不要自己实现直接用组件系统给出的 hitTest 结果前提是 item 的真实 frame 已更新。普通列表方案则天然命中正确因为每个 item 的 frame 就是实际 frame。无障碍也要注意滚轮组件一般会给辅助功能标记一个“可调节值”但不同 item 高度下辅助功能可能读不出当前选中的是哪一项。在普通列表方案里最好手动设置 accessibility 的 value值就是当前高亮的 item 文本。6. 我最终的选型建议和实际心得折腾完这一轮我给团队写了一个选型判断表按需求强度来推荐方案。需求特征推荐方案原因选项内容长度差异小UI 允许大量留白等高网格化改动最小、稳定性最高选项内容差异大但数量少10 个动态测量 自定义滚轮视觉最贴近滚轮效果选项内容差异大数量可能很多普通列表 居中高亮性能最稳支持任意高度Web 端移动端兼容为主CSS scroll-snap一行代码解决吸附只想要“能展示不同高度”且不要求 3D 滚轮效果普通列表 高亮线最省事接受度最高我最终在项目里选的是普通列表加居中高亮。原因很简单选项里有两行文字和图片高度差异大而且列表整体不超过 8 个 item不需要 3D 旋转来节省空间。用户实际感知上“中间有一条高亮线”和“滚轮停到中间”的区别非常小但维护成本差很多。回头看这个问题的本质ScrollWheel 的等高设计是为了用空间换取计算效率。而产品需求是变化的内容永远往更多样化的方向走。所以与其纠结“怎么让滚轮支持不同高度”不如想清楚“滚轮效果是不是这个页面必需的”。很多时候用户需要的只是一个能上下滑动、当前项清晰可见的选择控件而不是一个严格意义上的转盘。如果哪天产品经理说你一定要保留 3D 滚轮效果那再去自定义布局也不迟——但请做好连续调参的准备缩放比例、透明度渐变、远处 item 的最小尺寸每一个参数在高矮混合的列表里都要重新校准。这一步没有捷径只能拿真机反复试。最后再分享一个小技巧无论用哪种方案一开始就做一个“高度差异化调试页”把所有极端情况最长文本、最短文本、带图片、超长说明塞进去跑一遍。等上线后才发现某个特殊内容导致滚动跳位那就真的晚了。