Android Compose的布局间距确实是个容易让人迷糊的地方。很多从传统View体系转过来的朋友，第一反应是找layout_margin和layout_padding的替代品，然后就会被Modifier.padding、Arrangement.spacedBy、Spacer这些概念搞得头大。刚上手时我也一样，觉得明明只是“留点空白”这么简单的事，怎么到了Compose这里就有这么多讲究。但实际用下来才发现，这套设计其实比原来的View体系更优雅——间距不再是写在XML里的死参数，而是变成了一种可组合、可复用、可动态变化的布局策略。这篇文章就把我实际开发中踩过的坑和总结出来的经验一次性讲清楚，无论是刚接触Compose的新手，还是已经被间距问题折磨过一阵子的老手，都能找到有用的东西。
1. Compose间距体系的设计思路与核心概念
1.1 从View体系到Compose的思维转换
在传统Android开发里，控制间距靠的是两个属性：layout_margin（外边距）和layout_padding（内边距）。它们定义在XML布局文件里，由ViewGroup的LayoutParams决定，而且父子布局的处理规则各不相同。LinearLayout里有layout_marginLeft，RelativeLayout里有layout_alignParentLeft，ConstraintLayout还要专门引出个layout_goneMarginStart来应对GONE的View——规则多、逻辑散，时间久了全靠硬记。
Compose完全推翻了这套思路。间距不再是View的属性，而是Modifier的职责。一个控件间距长什么样，完全由Modifier链决定——先加padding再定size，结果就是整个组件撑开了；先定size再套padding，尺寸不变但内容被压缩了。这种模式下，间距变成了“装饰”而非“约束”，你可以像搭积木一样自由组合。
这种转换带来的最大好处是：间距不再跟具体的View类型绑定。传统写法里，LinearLayout有arrangement和LayoutParams，FrameLayout只有layout_gravity，每种布局都有自己的规则。Compose里Column、Row、Box有各自的管理方式，但最终都落在几个有限的概念上——Modifier.padding管的是元素自身的留白，Arrangement管的是子元素之间的排布距离，Spacer则是一个纯粹占位的“间距占位符”。把这几个点吃透，任何布局的间距问题都能拆解清楚。
1.2 间距的三种落点：外部、内部与元素之间
我习惯把Compose里的间距分成三个层面来理解，这套分法在排查问题的时候特别管用。
第一层是元素内部的间距，也就是padding语义。它作用于组件的内容区和边界之间，举一个最简单的例子：你给一个Button加Modifier.padding(8.dp)，按钮的实际尺寸不会变，但内容（比如文字或图标）会向中心收缩8dp。这时候padding更像是在“挖空”内部空间，而不是扩展外部边界。这里有个要命的细节，如果你先写Modifier.padding(8.dp)再写Modifier.height(40.dp)，按钮的整体高度会被撑到56dp；反过来先height后padding，宽度虽然不变，可内容区被压缩了。这种“先后顺序决定尺寸”的机制，和View时代“padding一定在内部算”的直觉完全不同。
第二层是元素之间的间距，对应Arrangement.spacedBy和Spacer。传统开发里，两个Button之间的水平间隔要写layout_marginStart，或者干脆在View之间塞一个透明的View占位。Compose的Arrangement.spacedBy(12.dp)直接声明“子元素之间留12dp”，不仅省去了给每个子View写margin的麻烦，还天然处理了“第一个元素和最后一个元素不要额外留白”的问题。这在视觉上非常讲究：一组排列整齐的图标，如果最左边还要空出一段“边距”，看起来就会歪。
第三层是子元素相对父容器的位置偏移，对应Modifier.padding(horizontal = 16.dp)这种带方向性的设置，或者Box中Modifier.align带来的偏移效果。它跟view里的layout_margin最接近，但有个区别：Compose里的margin语义不区分“父容器施加给子元素”和“子元素自己要求”的关系，一切只是自身修饰符的自我表达。
这里我还要单独说一下Spacer。有些人喜欢用Spacer(modifier = Modifier.size(16.dp))来控制距离，我却不太建议把它当成“margin的替代品”滥用。如果间距只在当前布局里用一次，Spacer完全没问题，但一旦你的设计稿间距是成体系的（比如基础间距4dp、8dp、12dp、16dp），用Arrangement.spacedBy + 枚举值来管理会更干净，因为spacedBy是全局声明的规则，而Spacer是每处插入的“冗余DOM”。
1.3 为什么说Compose这套设计更合理
我早年间写XML布局的时候，最痛苦的就是层级嵌套带来的性能损耗和margin重叠问题。一个RelativeLayout里，子View为了对齐左右两侧，经常写成layout_toLeftOf + layout_marginRight的组合，结果屏幕上的实际距离根本不是你想的那个值。Compose的单一MeasurePass机制让padding、offset、size可以按声明顺序精确计算，不存在View体系里多次测量、父类约束优先级的暗规则。
另一个更重要的点是可复用性。在View时代，间距是写死在XML里的，想根据屏幕宽度做响应式间距调整，几乎只能靠写多套布局或者用 dimens 资源。Compose里，间距是一个Dp值，它可以直接从配置类、主题、甚至是接口返回的动态数据中来。不同屏幕适配逻辑就是一句Modifier.padding(if (isTablet) 32.dp else 16.dp)，简单直接，还能配合StateFlow做动态热更新。这种灵活度，传统View里想都不敢想。
最后就是代码审查和协作上的优势。传统XML布局里，想搞清楚一个View的完整间距来源，得同时看三个地方：XML里的margin、父容器的padding、以及父容器LayoutParams里的规则。Compose里所有间距逻辑都写在Modifier链上，从代码流里从上往下读一遍，整个间距体系一目了然。人脑不需要维护一张隐性的依赖表。
2. 核心API细节拆解与间距设置的实操要点
2.1 Modifier.padding家族：普通padding与requiredPadding的差别
先说说Modifier.padding这个最常见的API。它的基础用法是Modifier.padding(16.dp)，代表四周统一留白16dp；也可以分方向写Modifier.padding(start = 12.dp, end = 12.dp, top = 8.dp, bottom = 8.dp)。还有一个常见组合是Modifier.padding(horizontal = 16.dp, vertical = 8.dp)，它和传统View的paddingHorizontal、paddingVertical是对应的。
但真正的坑在requiredPadding上。如果你在某段代码里用了Modifier.padding(20.dp)加上一个Row，并期望Row的子元素有20dp的间距缓冲，但实际测量时发现某些子元素（比如Text的宽度溢出）导致Row被无限撑大——这时候requiredPadding往往是救星。因为requiredPadding是不受“可被压缩”约束的：它强制给布局上一道不可跨越的间距下限，没有任何测量阶段可以把它优化掉。普通padding在某些布局约束下（例如父组件指定了固定最大宽度且子内容尺寸紧张）会被测量流程“妥协压缩”，而requiredPadding不会。
这点在实际开发里非常关键。我遇到过一种情况：父级是一个Modifier.constrainWidthAs(maxWidth = 300.dp)的容器，里面的按钮加了一个Modifier.padding(16.dp)。正常宽度下没问题，但当按钮字体调大或者翻译成德语这种长单词语言后，按钮的padding直接“被吃掉”一部分，文字反而顶到了容器边缘。换成requiredPadding就完全不会，因为requiredPadding在Constraints里是不可协商的硬下限。值得强调的是，这不是bug，而是Compose测量模型的一个特性——布局可以在受限空间中决定如何响应约束，普通padding默认是可以被裁剪掉的。
用法上，requiredPadding通常不需要修修补补地到处加，只有在你明确要让某块间距“雷打不动”时再用。如果你写的每个padding都用requiredPadding替代正常padding，那基本就是拿刑法当道德准则——过度设计，还会让可读性变差。
2.2 Arrangement：不只是对齐，更是间距规则的容器
Arrangement这个词，如果从传统LayoutParams的思路去想会懵，换成“布局策略”就清楚了。它决定了一组子元素在主轴上如何排布。Row（水平方向）的Arrangement控制的是子元素们如何横向分布，Column（垂直方向）控制的是纵向分布。
最基础的是Arrangement.Start、Center、End，它们分别对应线性布局里的左对齐、居中、右对齐。但真正跟间距相关的是另外四个：
- Arrangement.spacedBy(8.dp)：子元素之间均匀保持8dp间距，首尾无额外间距，是实际开发中最常用的一个。
- Arrangement.SpaceBetween：把空闲空间均匀分配给相邻元素之间，等价于“元素们贴得密密麻麻为一个整体，然后整体边缘贴合容器两端”。
- Arrangement.SpaceEvenly：每个相邻元素之间以及首尾两端都有相等的空间，表现形式就是第一个元素前面和最后一个元素后面也有空隙。
- Arrangement.SpaceAround：每个元素两侧都有等空隙，两端是中间空隙的一半，效果上有点像“每个margin都是8dp，但相邻的两个margin合起来用”。
这四个区别，我建议直接在Compose Preview里用不同背景色的Box试一遍，视觉记忆比文字描述来得直观得多。用完后你会发现一个大好处：SpaceBetween可以完全替代原来RelativeLayout里layout_marginStart/End加上layout_gravity的组合，写起来干净得多。
还有一个容易被忽视的点：Arrangement.spacedBy可以配合自定义Alignment来使用。比如spacedBy(8.dp, Alignment.CenterVertically)可以让子元素在纵向居中的同时，横向均匀排布8dp距离。这种复合控制之前需要同时写LinearLayout的gravity和每个子View的layoutParams，在Compose里一行搞定。
最后说一个性能上的点：spacedBy在布局阶段是“几何规则”，不是“真实视图”，它不会像Spacer那样创建额外的布局结点。在LazyColumn这种需要大量虚拟复用的场景里，用verticalArrangement = Arrangement.spacedBy(8.dp)来替代每个item的padding，能少创建无数个无意义的Spacer实例，对滚动性能是无形的提升。
2.3 内容感知的safeContentPadding与实际开发里的边缘情况
现在全面屏手机铺天盖地，间距问题不可避免地和系统安全区纠缠在一起。Compose提供了WindowInsets来感知状态栏、导航栏、系统栏等区域，进而为内容避让。最常见的场景是，你做了一个沉浸式布局，希望列表内容能从顶部一直“流”到状态栏底下，但每一条Item的文字不能被状态栏遮住。
这种情况下，最佳做法不是给每条Item加padding，而是给列表容器加上contentPadding参数。比如LazyColumn(contentPadding = PaddingValues(top = statusBarHeight))，这样只有第一条Item会被顶到安全区域内，后面的Item正常排列。你必须分清楚：contentPadding是“内容与容器边界之间的间距”，它和每个item自身是否被padding无关。很多新手把contentPadding理解成“给每个item都加一层padding”，结果是一屏只能看到两三行，特别诧异。
另一个容易踩的地方是WindowInsets的取值维度。WindowInsets.statusBars是一个基于密度归一化的Dp集合，在不同设备上返回的值会根据状态栏实际高度换算。这里最好别自己去写“状态栏高度=24dp”这种裸奔逻辑，适配任何设备都不靠谱。直接依赖WindowInsets.statusBars.asPaddingValues()才能保证不出偏差。
还有Modifier.windowInsetsPadding(WindowInsets.safeDrawing)这种写法，在Android 11以上系统里能同时避让状态栏、导航栏和圆角区域，是最稳妥的全屏场景初始值。唯一需要注意的是在复用组件里，如果外层已经做了windowInsetsPadding，内嵌的组件就不要重复再套一层safeDrawing，否则会出现“避让被叠加”的间距双击，这在横竖屏切换时特别明显——因为竖屏时statebar+navbar的高度和横屏时是两套不同数值，叠加后界面跳得很诡异。
3. 实操完整流程：从静态间距到动态配置
3.1 一个常见列表页的间距设计实例
看一段典型代码。假设要做一个文章摘要列表，每条item包含标题、摘要、作者信息三行，列表页整体左右留白16dp，卡片之间间隔12dp，卡片内容与卡片边界之间留白14dp。
@Composable fun ArticleListScreen(articles: List<Article>) { LazyColumn( modifier = Modifier.fillMaxSize(), contentPadding = PaddingValues( start = 16.dp, end = 16.dp, top = 8.dp, bottom = 24.dp ), verticalArrangement = Arrangement.spacedBy(12.dp) ) { items(articles, key = { it.id }) { article -> ArticleCard(article) } } } @Composable fun ArticleCard(article: Article) { Column( modifier = Modifier .fillMaxWidth() .background(MaterialTheme.colorScheme.surface, RoundedCornerShape(8.dp)) .padding(14.dp) ) { Text( text = article.title, style = MaterialTheme.typography.titleMedium ) Spacer(modifier = Modifier.height(6.dp)) Text( text = article.summary, style = MaterialTheme.typography.bodyMedium, maxLines = 2, overflow = TextOverflow.Ellipsis ) Spacer(modifier = Modifier.height(10.dp)) Text( text = article.author, style = MaterialTheme.typography.labelSmall, modifier = Modifier.alpha(0.7f) ) } }这段代码里我用了三个间距工具：LazyColumn的contentPadding负责整体页面留白，verticalArrangement = spacedBy(12.dp)负责卡片与卡片之间的缝隙，Card内部的Modifier.padding(14.dp)负责内容与卡片边框的呼吸空间。每个间距源都有明确职责，互不干扰，将来设计稿改间距时，能准确找到修改的位置，不用猜某个12dp到底是哪个属性。
关于卡片内部的间距，我有两个习惯。第一，最好不要用Modifier.padding直接包住Column的内容，而是在Column的modifier里直接加padding，这样背景色的边界和padding区域天然统一；第二，内部元素的间距用Spacer还是Arrangement.spacedBy，取决于这些间距是否几何均等。如果标题、摘要、作者之间的三个间距各不相同（6dp、10dp、8dp），用Arrangement.spacedBy只支持统一值，Spacer是更直观的方案，虽然多了几个“虚拟结点”，但视觉排布一目了然。
3.2 动态间距：怎么配置、怎么响应状态变化
Compose的间距是“值”而非“死代码”，天然适合响应数据和状态变化。最常见的动态需求有两种：一是跟随屏幕尺寸变化（手机、折叠屏、平板的密度适配），二是跟随用户设置变化（比如显示大小、无障碍缩放）。
先说屏幕适配。我习惯把间距定义为一组业务无关的基础常量，再根据当前窗口类型做映射：
object AppSpacing { val compact = LayoutSpacing(horizontal = 12.dp, itemGap = 8.dp) val medium = LayoutSpacing(horizontal = 20.dp, itemGap = 12.dp) val expanded = LayoutSpacing(horizontal = 28.dp, itemGap = 16.dp) } data class LayoutSpacing( val horizontal: Dp, val itemGap: Dp ) @Composable fun adaptiveSpacing(): LayoutSpacing { val configuration = LocalConfiguration.current return when { configuration.screenWidthDp >= 840.dp -> AppSpacing.expanded configuration.screenWidthDp >= 600.dp -> AppSpacing.medium else -> AppSpacing.compact } }然后将adaptiveSpacing()的返回值传给各个列表页或卡片组件。整个应用的间距就会跟随设备形态变化，却不需要任何if-else散落在每个组件里。当折叠屏展开或横竖屏切换时，配置重组触发数值更新，界面的留白宽度同步调整，整个过程中你不需要手动触发任何副效应。这在传统View里需要写onConfigurationChanged和自定义LayoutParams逻辑，写起来相当麻烦。
第二类是跟随用户设置变化的场景。比如App里提供一个“界面密度”开关，让用户自由调整卡片间距、列表间距的缩放倍数。这个在Compose里其实就是把一个Float值挂到ViewModel的StateFlow上：
val spacingScale by viewModel.spacingScale.collectAsState()然后所有间距计算地方统一乘上这个scale：
Modifier.padding(horizontal = spacing.horizontal * spacingScale)这样设置项的代码就写完了。但有一个坑，动态缩放间距时文本组件本身的文字大小并不会有感知会被重新测量，容易出现布局重排导致的“闪烁”，尤其在LazyColumn里更新scale时，Item间的间距跳跃非常明显。我当时的解法是把scale变化结合Modifier.animateContentSize()一起用，每次间距变化会平滑过渡，不会生硬地跳动。不过animateContentSize对LazyColumn的复用效率影响明显，如果列表很长，另外加一个AnimatedVisibility在外层或者直接接受跳变也是一种可选方案。
3.3 修饰符顺序对间距的真实影响：一个容易出错的检查点
间距这块石破天惊的坑，就是Modifier顺序。它决定了padding是加在内容外面还是内容里面。我找一个简单例子说明：
Box( Modifier .padding(16.dp) .size(100.dp) .background(Color.Red) )这样写的效果是：红色的Box只有100dp，但它外面还有一层16dp的透明空白区，整体会占132dp。如果你改写成：
Box( Modifier .size(100.dp) .padding(16.dp) .background(Color.Blue) )效果完全不同：红色Box还是100dp，但是蓝色Box变成了132dp，里面内容区是100dp。因为padding在size之后声明，它是在已确定的size基础上向内挤压出内容区；而padding在size之前声明，它先占据了一个96dp的区域，再加上16dp padding，再外部最终尺寸是100dp——蓝色Box这个例子实际上外面的100dp是size定下的，padding是在它里面又挖了一层，最终视觉上有背景的区域变窄了。
我在实际项目里见过最普遍的翻车场景是Button。给按钮加Modifier.padding(8.dp).height(48.dp)时，整个按钮高度会被撑到56dp，UI稿对不齐。解决方式就是调整顺序，写height(48.dp).padding(8.dp)，就能保证按钮总高度是48dp，内容区为32dp。但这里必须要想清楚——按钮文字如果有最小的触控高度限制，content区被压缩到很窄后反而会在视觉上引发“文字紧贴框边”的观感。所以正确做法是先保证高度是48dp，然后对内容做敏感适配。
还有一个常被忽略的细节：width和height这类尺寸修饰符，它们两个本身的顺序也会影响理解。Modifier.fillMaxWidth().padding()和Modifier.padding().fillMaxWidth()的最终外显尺寸一样，但如果后续还有background，背景的占位范围会根据padding放在background前后来回变化。最稳妥的做法是把background放在尺寸修饰符和padding之间，这样你看到的颜色范围永远是预期的最终绘制范围。
排查这类问题我的经验是：在Preview里摆一个不同颜色背景的Box，然后把Modifier的每一步都截图看一下，视觉差异比纯逻辑推理更快。Modifier的文档对顺序的说明也建议“先尺寸再间距”，这不是绝对的，但90%的场景下这样写不出错。
4. 间距问题排查与进阶避坑技巧
4.1 间距不生效或异常的五个隐藏原因
间距不生效是最折磨人的问题，因为大部分时候不是Compose不认你的写法，而是某个上游条件偷偷改变了布局语义。
第一个常见原因是父组件的Constraint。Column默认会要求子组件在垂直方向上有确定的尺寸，但如果你在Column里显式加了一个Modifier.weight(1f)的子组件，weight会占据父组件剩余空间，这时候给子组件加的padding（top和bottom）会导致剩余空间计算被过度消耗，出现视觉间距比预期大的情况。要确认是不是weight干扰，可以把weight改成wrapContentHeight再看间距。其实weight和padding的叠加逻辑本身没有错，只是它们共享同一块空间，一旦内存空间不够，padding的良好视觉比例就被打破。
第二是density单位问题。dp、px、sp三者的换算基于设备density，但Compose里如果你从外部系统（比如从服务器接口返回的px值）拿数据，直接套Modifier.padding(value.dp)会把px当普通整数当dp用，结果是跑到不同屏幕密度的设备上，间距忽大忽小。这个问题的正确解法是用Density.run { value.toDp() }做一次转换，把px转换成当前设备的dp值。服务器下发px间距本来就是接口设计有问题，但因为项目周期紧只能由客户端自己消化的场景，这个坑必须注意。
第三是LazyColumn里的Item复用导致的间距残留。很多人在Item内部用Modifier.padding(top = 16.dp)来区分首个Item和后续Item的位置，但复用时item的state可能带着上一屏的参数，导致滚动后某些Item的间距忽大忽小。更好的做法是：把间距从item内部移除，改由LazyColumn的contentPadding或verticalArrangement来统一控制。项目里只有一个逻辑要区分“第一项”和“最后一项”的特殊间距时，可以用itemsIndexed拿到index，在第一个Item上单独追加PaddingValues——但不要放到item composable内部，而是用内容API的forEachIndexed动态生成带有不同padding的子Item。
第四是Box的位置偏移。很多设计稿需要在Box里对子元素做“边距偏移”，但Box的默认alignment是TopStart，所以子元素加padding后，整体位移是“相对左上角”的。如果你用Modifier.align(Center)再套padding，它的计算基准就变成容器中心，视觉上可能测出来环绕四周的距离不是一致值——因为padding是对自身内容的收缩，而不是对容器边的距离。想实现真正的“内部居中后再距边多少”，用Modifier.offset或者expandContentSize更稳妥。
第五，也是很多人的灰色地带：Spacer会占父级尺寸测量结果。如果你在Row里写了Spacer(Modifier.weight(1f))，同时又给Row设置了Arrangement.SpaceBetween，你会发现整体件的分布和预期的不一样——因为这个Spacer承担了分配空间的角色，SpaceBetween的算法面对一个“空间分配器”时，会自动把它的尺寸计算为零，于是剩余Space全部按三分法平摊到两侧的视觉间隔上，场景是“两边的item被挤得异常远”。这种问题排查起来最难，因为代码上并没有任何明显错误。解决方式是明确：要么用Spacer做弹性区间，要么用Arrangement做空间分配，别在同一容器里混用两种策略。
4.2 状态栏与安全区的间距处理：从windowInsets到contentPadding
很多APP的沉浸式页面会和状态栏打交道。使用windowInsetsPadding是首选的仪表板API，基本代码如下：
@Composable fun HomeScreen() { Box( modifier = Modifier .fillMaxSize() .background(Color.White) .windowInsetsPadding(WindowInsets.safeDrawing) ) { // 列表内容 } }代码看着简单，但实际业务里我建议把“页面根容器避让”和“列表内容避让”分开。如果直接在Box外加windowInsetsPadding，那么列表的RecyclerView不允许到延伸到状态栏底部把整个“沉浸”，所以你的背景色会在状态栏对应的区域落一个白条，对于看视频或者全屏画廊这种想让背景渗进状态栏的场景，这是不对的。
正确做法是分层处理：
@Composable fun HomeScreen() { Box( modifier = Modifier .fillMaxSize() // 背景铺满整个区域，让沉浸生效 ) { // 顶部Toolbar单独处理状态栏 TopAppBar( modifier = Modifier.windowInsetsPadding(WindowInsets.statusBars) ) // 内容列表使用contentPadding规避导航栏 LazyColumn( modifier = Modifier .fillMaxSize() .windowInsetsPadding(WindowInsets.navigationBars), contentPadding = PaddingValues(...) ) { ... } } }这样做可以让背景和底部内容“穿插”进安全区，列表滚动时完全沉浸，而操作按钮和标题永远正确避让。能理解这套“背景铺满+内容避让”的分层思想，沉浸式页面的间距设计就过关了。
这里还要提一下screen和safeDrawing的取舍。safeDrawing包含的内容比较全（状态栏+导航栏+系统栏+手势导航条），但注意它在个别设备会上浮一个极小的值，因为Android 15开始强制edge-to-edge模式，系统的WindowInsets和传统动画不同步。如果你发现安全区高度“多出来几像素”导致顶部多出一条缝，可以换成WindowInsets.safeContent或statusBars+displayCutout的组合做修正，而不是裸写减法。
4.3 间距在列表和动画场景的性能陷阱
Compose不是神，间距用得不小心会拖慢UI。我发现几个典型的性能陷阱，值得展开说。
第一个是Spacer滥用。在LazyColumn里，如果你想做一个总是悬停在列表底部的间距，放在contentPadding里是最合适的，它会和列表所有item统一计算。而如果在每个item底部使用了Spacer，等于每个Item白白多了一个测量节点。虽然Compose对Spacer这类“空布局”优化得不错，但列表一长，节点数量翻倍，测量时间也会跟着上涨。为了保证滚动流畅，我坚持LazyColumn里的Item内部间距优先用内边距和Arrangement，Spacer只用来处理“静态布局里数量少但视觉不平衡”的局部间隙。
第二个是动态间距和动画的组合问题。如果你用Modifier.animateContentSize配合间距变化，比如用户切换“界面密度”设置后，间距从16dp动态变化24dp，你会发现间距变化的动画其实作用在padding上，但背景的渐隐和文字重排可能不同步。实测后我建议：大范围间距动画（超过8dp的变化）不要靠animateContentSize，而是用animateDpAsState把间距本身做成状态，然后让要变化的组件“读状态并重组”。虽然Recompose范围更大，但视觉上更平滑。
第三个是recompose scope的问题。Modifier.padding如果引用了一个可变的State值，这个State变化时只有这个Modifier依赖所在的作用域会重组。但如果这个padding经常被Activity级全局变量更新，那Compose会把这个Box乃至它的父容器全部重绘——这其实不是间距本身的坑，而是状态设计的问题。把间距状态用derivedStateOf收敛到只有布局变化的组件上，能省掉一大半不必要的重组。
4.4 一份间距问题的自查清单
下面是我整理的自查清单，遇到间距问题可以按顺序排查，基本不会漏。
| 出现问题 | 最大嫌疑 | 排查要点 |
|---|---|---|
| 间距比设计稿大/小 | 修饰符顺序或Constrains影响 | 按设计稿尺寸反推总大小，检查padding是否先于size写 |
| 某方向padding不起效 | parent的MeasurePolicy | 自定义Layout里可能会覆盖子项的Constraints |
| 子元素距父容器不对称 | 父容器Arrangement/Alignment影响 | 检查SpaceEvenly/SpaceAround是否被使用 |
| LazyColumn滚动后间距跳变 | item复用状态残留 | 内部padding移出item，统一用contentPadding |
| 沉浸页面距离状态栏错位 | WindowInsets被主体重复避让 | 检查多个windowInsetsPadding是否叠加 |
| 动态间距闪跳 | 状态变化/重组整体开销过大 | 改用animateDpAsState + 收敛Scope |
这个表格还不是全部，但已经覆盖了我项目里九成以上的线上问题。最值得反复敲打的就是“修饰符顺序”和“约束是否覆盖”这两类，几乎每个间距bug最终都归到这两个源头。排查的时候先看代码里的Modifier链顺序，再从外到内检查父容器的布局参数，最后再看当前组件的自身Constraints是否被父类“截胡”了。
另外，我强烈建议每个项目开发初期就定好一套全局Spacing枚举。不要今天写一个12.dp，明天写一个11.dp，后天又冒出来12.dp但其实是给图标用的。我在自己团队里推行的做法是：定义LayoutSpacing和SizeSpacing两个data class，LayoutSpacing管margin/padding的节奏感，SizeSpacing管组件本身的宽高规格。所有间距值只能从这两个类取值，不允许手写裸dp。半年下来，设计走查的返工率确实降了不少，因为大家的眼睛会习惯同一套“拍子”。
经验越积累，你越会发现，间距设置本身不是难题，真正难的是在复杂页面里保持节奏的一致性。如果你能建立一个统一的间距数值体系，再配合Modifier顺序和Arrangement的良好习惯，基本不会再被Compose布局间距折磨。
我自己走到这一步之后，回过头最庆幸的是从一开始没有回避Modifier顺序这道坎。当时为了搞懂padding先写和后写到底有什么差别，专门写了一个三十个Box排列的Demo，每种顺序组合都截了图。那段折腾虽然看起来笨拙，但攒下来的直觉，比读十篇文档都好用。你现在要是还在为间距发愁，也可以这么做一遍，相信我，这是最快的内化路径。
