做Unity UI的兄弟应该都有过类似经历想做个简单的滚动列表从教程或模板里拖了个ScrollView下来把Item丢进Content里改改位置运行一看——要么滚不动要么Item四散飞走要么Scrollbar跟内容完全不同步。最气人的是参数看起来都配对了一到真机测试就被打回原形。Scroll View下的Content设置说白了就是一句话的事让Content的尺寸正确、锚点正确、布局正确。但这三件事一旦放到实际项目里就会牵扯出锚点、Pivot、Content Size Fitter、Layout Group、Mask、滚动边界计算、动态加载、对象池……一大堆问题。这篇文章不聊怎么从零手搓一个ScrollView而是把最容易出错也最容易被一句带过的Content配置从原理到实操拆开讲清楚每个参数到底在干什么、为什么这么配并附上实际踩坑记录和排查清单。手头正在做列表页、背包、排行榜、聊天框的人应该都用得上。1. 组件结构拆解先弄明白Scroll View为什么会“滚动”1.1 一张图看懂的层级关系很多新手第一次看ScrollView的Hierarchy会蒙圈为什么新建出来有四个子物体Viewport、Scrollbar Horizontal、Scrollbar Vertical、Content而且Content还套在Viewport下面。这个结构不是随意设计的它直接决定了Content的设置思路。先把这个层级对应关系捋清楚Scroll View根节点挂Scroll Rect组件负责接收滚轮、拖拽、惯性等输入并通过代码计算Content应该偏移多少。Viewport一个带Mask组件的Image区域是内容的“显示窗口”。它只显示落在自己范围内的子物体超出部分会被裁剪掉。Content真正的“可滚动内容容器”所有Item都挂在它下面。Scroll Rect控制的就是Content的localPosition。Scrollbar本质是一个Slider把Content当前偏移量映射成0到1的归一化值也可以反向控制Content位置。注意一个容易混淆的点Content和Viewport是父子关系但滚动时移动的是Content不是Viewport。Viewport是固定不动的“窗户”Content是窗户后面移动的“长画卷”Mask负责把画卷超出窗户的部分藏起来。这个结构背后还有一个隐藏细节Content的RectTransform的position是相对于Viewport的但因为父级是Viewport所以Content的localPosition其实是相对于Viewport的中心点还是某个锚点位置这取决于Content的Anchors和Pivot。很多人卡在“Content明明设置了尺寸为什么滚动范围不对”上十有八九是这里没搞清。1.2 为什么Viewport的Mask不能乱动在实际项目里有人嫌Viewport自带的Image碍事直接把Image组件删了有人觉得Mask影响性能把Mask也去了还有人为了让背景好看把Viewport的Image换成了半透明图。结果就是列表内容串到画面外面或者滚动时背景也跟着飘。这里需要明确Viewport上的Mask负责裁剪Image组件只是Mask的载体也就是不需要显示任何图也不能删掉Image。因为Mask组件本身依赖一个Graphics组件来定义“蒙版形状”Image就是那个Graphics。如果你把Viewport的Image删了Mask会因为没有渲染载体而失效整个列表就“遮不住”了。所以正确做法是保留Viewport的Image组件将Image的Color透明度改为0Source Image保持NoneRaycast Target取消勾选。这样才能既裁剪内容又不遮挡视觉、不拦截点击。至于“Mask影响性能”的说法针对于小列表影响不大。如果列表Item数量特别多、而且每个Item自身还嵌套复杂UI可以考虑把Mask换成RectMask2D。RectMask2D的裁剪是基于矩形区域的开销比Mask小不少而且不需要依赖Image载体。但要记住RectMask2D的裁剪区域是它自身RectTransform的矩形范围所以Viewport的尺寸必须正确否则裁剪区域会跟着Content跑。1.3 Scrollbar的工作原理其实就是一个双向绑定的SliderScrollbar和ScrollView之间不是“父子绑定”这么简单它是通过Scroll Rect组件上的Horizontal Scrollbar / Vertical Scrollbar两个槽位关联起来的。Scrollbar自身又是一个Slider的变体有一个Handle滑块、一个Background背景。它的工作原理可以这样理解当Content偏移量变化时ScrollRect把“当前偏移量 / 最大可偏移量”算成一个0到1的数值赋值给Scrollbar的value。当玩家拖动Scrollbar滑块时Scrollbar的value变化ScrollRect反过来根据这个value推算出Content应该偏移多少。这个双向绑定决定了两个调试方向如果Content尺寸算错了Scrollbar的滑块长度和位置会看起来不正常。如果Scrollbar被单独调整了Anchor或RectTransform尺寸会导致它跟Content对应不上出现“滑块到底了内容却还剩一半”等情况。正常情况下Scrollbar的RectTransform不需要做太多改动保持默认即可。唯一需要注意的场景是把Scrollbar放在屏幕另一侧比如把Vertical Scrollbar挪到左边此时只需调整它的Anchor和PosX不用改其它任何逻辑。2. Content的核心配置Anchors、Pivot和SizeFitter2.1 Anchors的三种挂载策略Content的Anchors决定了它相对于Viewport的定位方式。这可以说是滚动的“地基”。我分三种典型场景讲。第一种纵向滚动最常见的列表Anchor和Pivot必须设置为顶部对齐AnchorsMin (0, 1)Max (0, 1)也就是“Top”PivotX0.5Y1为什么因为Anchor在顶部时Content的localPosition.y的0点就是Viewport的顶部。向下滚动时Content的localPosition.y从0变成负数比如 -660Content的底部一条条从Viewport底部滑出。如果你把Anchor设在中心Content会在Viewport的中心位置展开上下都能滚动看起来就像“内容悬浮在半空”用户体验非常怪。第二种横向滚动Anchor和Pivot都靠左AnchorsMin (0, 0.5)Max (0, 0.5)也就是“MiddleLeft”PivotX0Y0.5向右滚动时Content的localPosition.x从0变成负数。如果列表是从右往左增长像聊天室从底部开始则把Pivot的X设为1Anchor靠右。第三种双向滚动自由拖拽的地图、大画布这种情况下Anchor通常设为居中Pivot设为(0.5, 0.5)Content的尺寸比Viewport大可以上下左右任意拖动。这时候Content的初始位置一般是Viewport中心。这里有个很容易被忽略的细节修改Anchors后最好顺手把PosX、PosY、Width、Height重置一次。因为Anchors变化后RectTransform的Width/Height可能变成被拉伸状态蓝色十字模式你需要切回“宽高固定”模式再填入具体数值否则后面所有尺寸设置都会表现得很诡异。2.2 Pivot对滚动行为的影响Pivot是Content自身的“重心点”。很多教程直接让你把Pivot设为(0, 1)但不解释为什么。我举个反例假设Content高度是1380Viewport高度是720Pivot是(0.5, 0.5)Anchor是顶部。滚动到底时Content本地坐标Y应该是多少Content要往上移动的距离是Content高度 - Viewport高度 1380 - 720 660。但Pivot在Content中心时localPosition的0点对应的是Content中心与Viewport锚点重合的位置。于是当Content顶部对齐Viewport顶部时localPosition.y实际上是-Content高度/2 -690滚动到底则是-690 - 660 -1350。这个数不是0和-660导致Scrollbar的归一化映射完全对不上滚动范围也会超出预期。把Pivot设成(0.5, 1)后Content的localPosition.y0时就表示Content顶边贴着Viewport顶边滚动到底就是-660逻辑清晰Scrollbar映射也准确。所以Pivot的选择本质是为了让“Content的本地坐标”和“视觉上的对齐关系”保持一致。纵向滚动用Y1横向滚动用X0双向滚动用(0.5, 0.5)。2.3 Content Size Fitter的使用边界Content上挂Content Size Fitter时有两个选项Horizontal Fit控制宽度是否由子物体撑开Vertical Fit控制高度是否由子物体撑开纵向列表通常只需要把Vertical Fit设为PreferredSizeHorizontal Fit设为Unconstrained。这样Content的高度会根据Layout Group计算出的preferredHeight自动变化宽度则保持你手动设定的值。但Content Size Fitter不是万能的有几个典型坑当Horizontal Fit也设为PreferredSize时如果子Item的宽度是变量Content宽度会被“最宽的Item”撑开可能无意中超出Viewport宽度产生你根本没打算有的横向滚动。这点在排行榜、聊天框里特别常见Item里的文本一旦变长整个列表宽度就会抖动。Content Size Fitter和手动改SizeDelta不能共存。你刚手改完Content高度下一帧布局重建时就会被Fitter覆盖看起来就是“改了没用”。如果Content下没有Layout GroupContent Size Fitter的PreferredSize来自Content自身的RectTransform的sizeDelta的计算值此时它只会读取子物体的尺寸和位置没有布局组件参与。这种方式很不稳定不推荐。所以我的原则是有Content Size Fitter就必须配合Layout Group要手动管理尺寸就别挂Fitter。二者选其一不要混在一起。3. 布局铺排与数量计算Layout Group的组合拳3.1 Layout Group的选型Content下的子物体排布最省事的做法是挂Layout Group组件。三种Layout Group对应三种布局方式Vertical Layout Group纵向排布适合列表。Horizontal Layout Group横向排布适合Tab条、图标栏。Grid Layout Group网格化排布适合背包、图鉴、卡片墙。选型的核心依据是“Item尺寸是否均匀”。如果所有Item尺寸一致强烈建议用Grid Layout Group因为它本质上同时处理了横向和纵向的排布还能统一控制每行每列的数量。如果你的Item高度参差不齐比如评论列表、动态流用Vertical Layout Group更合理因为每个Item可以有自己的高度不会因为网格固定单元格而浪费空间。无论哪种Layout Group都要关注四个关键参数PaddingContent四周的留白。相当于滚动内容的“安全边距”。Spacing子物体的间距。注意这个间距是同一方向上“固定”的不会因为Item高度变化而动态调整。Child Alignment子物体的对齐方式控制每一行/列整体处于Content的哪个位置。Control Child Size / Use Child Scale / Child Force Expand后面三个选项里最有用的是Control Child Size。比如Grid Layout Group里勾选Width和Height后会强行把每个子物体的宽高拉伸到Cell Size这在做固定卡片大小的网格时非常实用。Child Force Expand默认不要勾否则每个子物体会被强制拉伸去填满剩余空间造成不可控的间隔。3.2 估算Content尺寸的完整计算过程当你不想依赖Content Size Fitter、而是手动控制尺寸时就必须自己算Content高度。这里给一个可直接套用的公式。假设场景如下Viewport高度 H 720Item高度 h 120Spacing 20数据条数 N 10Content的Paddingtop 20bottom 30Content高度计算公式Content高度 Padding.top N * h (N-1) * Spacing Padding.bottom代入数值Content高度 20 10 * 120 9 * 20 30 1430最大可滚动距离为可滚动距离 Content高度 - Viewport高度 1430 - 720 710当Content的localPosition.y从0变到-710时列表从顶部滚到底部。这里的完整推导很直观但实际开发中会有两个变数Item高度不固定。比如聊天内容有长有短不能只靠一个h值算总数。这时你需要遍历所有数据累加高度或者直接交给Layout Group Content Size Fitter自动计算。有Header和Footer。比如列表顶部有个Banner底部有“加载更多”按钮。别偷懒把Header/Footer也当成普通Item处理而是把它们当作Content的直接子物体在上面的公式里额外加上它们的高度。手动计算的好处是可控性极强配合对象池做虚拟滚动时能准确判断哪些Item在可视区域内。缺点是一旦Item高度发生变化就必须手动刷新。所以项目初期如果列表结构简单、数据量小建议直接Layout Group Content Size Fitter数据量超过几百以后再考虑手算 虚拟列表方案。3.3 手动创建Item时别忘了强制刷新布局很多人写出类似代码动态给Content添加一批子物体然后立刻读取Content的rect.height发现读出来是旧值于是各种“玄学”排查。原因很简单UI布局是延迟重建的。Layout Group的排版发生在下一帧的布局重建阶段而不是Instantiate的那一帧。你Instantiate完马上读rect.height读到的是上一帧的旧布局缓存。解决办法有两种方案一等一帧再读yield return null; float height contentRect.rect.height;方案二强制同步重建using UnityEngine; using UnityEngine.UI; LayoutRebuilder.ForceRebuildLayoutImmediate(contentRect); float height contentRect.rect.height;ForceRebuildLayoutImmediate是同步的调用完立刻返回最新布局结果。但它只对传入的RectTransform及其子物体生效如果布局里还嵌套了其它Layout Group也要一并Force一次。这个细节在“根据Content真实高度判断是否需要加载更多”的场景里特别重要。否则你拿到的永远是旧高度导致翻页逻辑反复触发或永远不触发。4. 动态生成Item与对象池别让Content变成“重量级选手”4.1 预生成和动态生成的取舍小数据量几十条以内的列表直接在Awake或Start里把所有Item实例化挂到Content下就行简单、好调试。一旦数据量到几百上千问题就来了。我做过一个通讯录列表数据是800个联系人每个Item有头像、名字、在线状态等组件。一次性实例化800个GameObject启动时卡了将近2秒就算启动不卡因为每个Item每帧都会产生UI重建和批处理开销实时帧率也被拖到很低。所以大列表必须上“动态生成”或者“对象池”。两者有区别动态生成只在Content可见范围内创建Item滚动时实时创建新Item回收旧Item。对象池就是先准备一批不激活的模板需要时取出激活不需要时回收禁用避免反复Instantiate/Destroy。在实际项目中两者是配合使用的对象池负责管理Item的实例动态生成逻辑负责决定哪些Item实例出现在Content中、以及放置到什么位置。4.2 基于对象池的手动刷新方法这里给一个完整可用的思路适用于固定Item高度的虚拟列表。假设Item高度固定为120Spacing为20Viewport高度720。第一步计算可见区域能容纳多少个Item可视Item数量 Mathf.CeilToInt(H / (h spacing)) 2 Ceil(720 / 140) 2 6 2 8额外加2是为了让滚动过程中上下各多一个“缓冲”Item避免在快速滚动时出现白屏。第二步监听ScrollRect的onValueChanged也就是Content位置变化时触发刷新。using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; public class VirtualList : MonoBehaviour { public ScrollRect scrollRect; public RectTransform content; public GameObject itemPrefab; public int itemHeight 120; public int spacing 20; public int totalCount 1000; public int viewportHeight 720; private ListRectTransform activeItems new ListRectTransform(); private StackGameObject pool new StackGameObject(); private void Awake() { scrollRect.onValueChanged.AddListener(_ Refresh()); Refresh(); } private GameObject GetItem() { if (pool.Count 0) { GameObject go pool.Pop(); go.SetActive(true); return go; } return Instantiate(itemPrefab, content); } private void RecycleAll() { foreach (var item in activeItems) { item.gameObject.SetActive(false); pool.Push(item.gameObject); } activeItems.Clear(); } private void Refresh() { // 当前滚动偏移向下为正 float scrollOffset -content.localPosition.y; // 当前可视区域内起始Item索引 int startIndex Mathf.FloorToInt(scrollOffset / (itemHeight spacing)); // 可见范围内Item数量 int visibleCount Mathf.CeilToInt(viewportHeight / (itemHeight spacing)) 2; RecycleAll(); for (int i startIndex; i startIndex visibleCount; i) { if (i 0 || i totalCount) continue; GameObject go GetItem(); RectTransform rt go.GetComponentRectTransform(); // 设置Item位置向上排布 rt.anchorMin new Vector2(0, 1); rt.anchorMax new Vector2(0, 1); rt.pivot new Vector2(0.5f, 1f); rt.anchoredPosition new Vector2(0, -i * (itemHeight spacing)); // 设置Item大小 rt.sizeDelta new Vector2(content.rect.width, itemHeight); // 在这里给Item填充数据go.GetComponent...().SetData(dataList[i]); activeItems.Add(rt); } } }注意这段代码有两个设计点一是scrollOffset取反是因为Content向上移动时localPosition.y为负取反后为正方便计算起始索引。二是每次滚动都会RecycleAll再重新创建所有可见项。这种方式实现简单但每帧滚动都会有激活、失活操作。如果滚动频率高可以优化成只回收“滚出视野”的Item、只创建“滚入视野”的Item而不是全量重建。不过对于多数项目这个版本的性能已经足够关键是把Instantiate/Destroy这两个高开销操作彻底去掉。使用对象池后还需要配合手动设置Content高度。因为此时Content下并没有所有ItemContent Size Fitter计算不出正确高度。正确做法是content.sizeDelta new Vector2(content.sizeDelta.x, totalCount * itemHeight (totalCount - 1) * spacing paddingTop paddingBottom);这一步千万不能漏。Content的尺寸是所有滚动逻辑的基础对象池只接管Item实例Content尺寸还得我们自己保证准确。5. 滚动定位与交互增强从“能滚”到“滚得准”5.1 滚动到指定Item的两种实现排行榜需要定位到第50名聊天框需要滚到最新一条消息这种“打开页面直接定位到指定对象”的需求很常见。实现方式有两种取决于Content是否挂Layout Group。如果Content有Layout Group最稳的做法是设置ScrollRect.normalizedPositionusing UnityEngine; using UnityEngine.UI; public static class ScrollViewExtensions { // 纵向滚动targetIndex 从0开始 public static void ScrollToIndexVertically(this ScrollRect scrollRect, int targetIndex, int totalCount) { if (totalCount 1) { scrollRect.verticalNormalizedPosition 1f; return; } float targetNormalized 1f - (float)targetIndex / (float)(totalCount - 1); scrollRect.verticalNormalizedPosition Mathf.Clamp01(targetNormalized); } }这里的公式逻辑是当targetIndex为0时normalizedPosition应为1滚到顶部targetIndex为最后一项时应为0滚到底部。所以用1 - targetIndex / (totalCount - 1)转换。但要注意这套公式只在所有Item高度一致时成立。如果Item高度不一致normalizedPosition和具体Item的对应关系会偏差很大只能算“近似定位”。如果Item高度不一致或希望精确到像素直接设置Content的anchoredPosition更靠谱public static void ScrollToPixelOffset(this ScrollRect scrollRect, float offsetY) { RectTransform content scrollRect.content; // offsetY表示从Content顶部往下数多少像素 content.anchoredPosition new Vector2(content.anchoredPosition.x, offsetY); }但设置anchoredPosition之前必须先保证Layout已重建否则计算出来的offsetY对应的Item位置还是旧的。所以稳妥的顺序是先LayoutRebuilder.ForceRebuildLayoutImmediate(scrollRect.content)再设置位置。这里还有个小坑anchoredPosition的正负号方向取决于Pivot和Anchor。当Anchor在顶部、Pivot的Y1时向下偏移的offsetY对应正的anchoredPosition.y。如果感觉方向反了试着取负即可。5.2 惯性、弹性与滚轮手感调节Scroll Rect组件上有几个参数直接决定了列表的“手感”Movement Type有三种。Elastic是默认的超出边界会有一个弹跳回弹效果Clamped是没有回弹直接卡在边界Unrestricted是不限制边界可以无限拖出去。Elasticity回弹力度数值越小回弹越快。Inertia惯性开关。开启后松手会有滑动余速关闭则拖动后立即停止。Deceleration Rate惯性减速速率0.135是Unity默认值。数值越小惯性衰减越快滑动距离越短数值越接近1越容易滑很远。Scroll Sensitivity滚轮滚动一个单位时Content位移多少像素。默认是1但在不同分辨率下体验差异大。我的经验是这个值最好跟实际UI缩放挂钩例如在1280x720下实测滚轮滚一格移动120像素左右手感合适那么在1080p下就要相应放大。弹性的类型选择上竞技类游戏榜单常用Clamped因为操作直接、不带回弹卡牌抽卡界面用Elastic会更灵动给人一种“有生命力”的感觉。没有绝对标准按项目调情即可。6. 常见问题与排查技巧实录6.1 Content就是滚不动最常见的三大原因Content的高度没大于Viewport高度。列表只有3个Item每个Item高100Viewport高720Content高度约300多压根不需要滚动。此时ScrollRect不会产生滚动。先检查Content的高度把Content选中看RectTransform面板里的Height如果小于Viewport Height那就先确认数据数量、Item尺寸、Spacing、Padding有没有设置对。Content的锚点或Pivot不对。比如纵向列表的Anchor没设成Top导致Content的本地坐标与ScrollRect的期望不一致。快速排查方式把Content的Anchors预设切成TopPivot的Y设为1再试。Scroll Rect的Vertical被关了。这是个很蠢但经常发生的坑。检查ScrollRect组件Horizontal、Vertical选项决定了轴向是否允许滚动。还有一种隐蔽情况Content下虽然有很多Item但Item的Layout Group没有生效所有Item叠在同一个位置Content的实际尺寸被Layout组件计算后要么是0要么很小。检查Item级有没有布局组件冲突比如同时挂了Horizontal Layout Group和Vertical Layout Group或者Item的RectTransform宽度设成了负数。6.2 Item位置偏移、错乱这类问题的“元凶”通常是Content的Pivot和Item的Anchor不一致。比如Content的Pivot是(0.5, 1)Item的Anchor却设在中心那么Item在Content内部的位置计算会基于各自的Pivot导致整体往上或往下偏移半个Item高度。排查思路很简单把Content的Pivot、所有Item的Anchor、Item的Pivot统一成同一套坐标系。纵向列表统一为“顶部对齐Anchor TopPivot Y1”横向列表统一为“左侧对齐Anchor LeftPivot X0”。不要在同一个列表里混用不同对齐方式除非你很清楚每个坐标偏移的后果。另一个常见问题是动态生成的Item使用了transform.SetParent(content)之后没有重置localScale、anchoredPosition、sizeDelta。从对象池拿出来的Item之前的anchor和偏移量会被带到新位置上。我建议在Item从对象池取出后立刻统一重置rt.anchorMin new Vector2(0, 1); rt.anchorMax new Vector2(0, 1); rt.pivot new Vector2(0.5f, 1f); rt.anchoredPosition new Vector2(0, -index * (itemHeight spacing)); rt.sizeDelta new Vector2(contentWidth, itemHeight); rt.localScale Vector3.one; rt.localRotation Quaternion.identity;反过来说如果复用的Item没有被完整重置就会出现“上一个Item残留位置导致新Item乱飞”的灵异现象。6.3 运行时Content高度不刷新这个问题在“加载更多”场景里最频发列表先加载20条滚动到底部后追加10条但Content的高度没有变化列表依然只能滚动到原来的位置。原因就是前面提到的布局延迟追加Item后并没有立即触发布局重建。正确做法是在追加完所有新Item、设置好LayoutGroup子物体后显式调用LayoutRebuilder.ForceRebuildLayoutImmediate(scrollRect.content);但如果Content挂了Content Size Fitter强制重建也不是每次都有效。一个保险手段是先调ForceRebuildLayoutImmediate再主动设置一次Content的sizeDelta最后再Force一次。这招在极端情况下能解决Unity布局系统缓存未失效的问题。另外如果Content的高度是通过代码直接赋值的那么追加Item后要重新计算总高度并重新赋值。别只增加子物体数量却忘记更新Content本身的高度这不是布局系统的问题纯粹是逻辑遗漏。6.4 嵌套ScrollView时手势冲突在排行榜Item里嵌一个横向滑动区域比如Item内有一个左右滑的图片轮播外层列表是纵向滚动这是最典型的嵌套滚动场景。默认情况下ScrollRect会拦截所有拖拽事件内层滚动根本无法响应。常见处理办法有两种简单版内层ScrollRect的Movement Type设为Clamped同时在代码里检测触摸起始方向。如果手势偏向水平就禁止外层纵向滚动的响应如果偏向垂直就禁止内层横向响应。需要在ScrollRect的OnBeginDrag和OnDrag里做方向判断。彻底版重写ScrollRect的OnInitializePotentialDrag、OnBeginDrag、OnDrag、OnEndDrag根据Input.GetTouch(0).deltaPosition的向量方向动态启用/禁用父子两个ScrollRect的horizontal和vertical。我实际使用中简单版在大多数UI框架下就能满足需求。只有在内层Item也需要支持复杂手势比如地图拖拽、多指缩放时才需要重写底层手势分发。判断方向时要留一个阈值通常取斜率|dy / dx|大于1判定为纵向手势小于1判定为横向避免像素级别的误判导致滚动卡顿。结尾前最后一个实战技巧最后分享一个我自己常驻的小工具方法专门用来“无痛初始化”Content。每次新开列表页我都会先执行这一套配置把基础调好再写业务逻辑public static void ResetListContent(RectTransform content, RectTransform viewport, Vector2 anchor, Vector2 pivot, Vector2 sizeDelta) { content.anchorMin anchor; content.anchorMax anchor; content.pivot pivot; content.anchoredPosition Vector2.zero; content.localScale Vector3.one; content.sizeDelta sizeDelta; // 清空旧子物体 for (int i content.childCount - 1; i 0; i--) { #if UNITY_EDITOR Object.DestroyImmediate(content.GetChild(i).gameObject); #else Object.Destroy(content.GetChild(i).gameObject); #endif } LayoutRebuilder.ForceRebuildLayoutImmediate(viewport); LayoutRebuilder.ForceRebuildLayoutImmediate(content); }这个方法帮我在项目里省了不少排查时间。做Unity UI开发很多问题不是“代码写得不对”而是“RectTransform的状态不对”。RectTransform的参数环环相扣Anchor影响Pivot的参考系Pivot影响localPosition的数值Layout Group影响sizeDelta的最终结果SizeFitter又反过来覆盖你手动的设置。搞懂了这一整条链路ScrollView的Content设置就不再是玄学而是一个完全可控的工程问题。
