Modifier.intrinsicSize.Min/Max与wrapContent系列修饰符有何区别？

现象产生的原因 #

首先明确Jetpack Compose的核心测量规则：父容器先向子元素传递尺寸约束，子元素在约束范围内计算自身尺寸后返回给父容器，父容器再基于子元素返回的尺寸确定最终自身尺寸。
你遇到的两种表现差异，本质是两种修饰符走的测量逻辑完全不同：

使用wrapContentHeight()时占满全屏的原因 #

wrapContentHeight()的作用是：在父容器传递的高度约束范围内，将自身高度适配为子元素请求的高度。
你给Surface的子Column设置了Modifier.fillMaxSize()，此时Column会向Surface返回的高度请求为父容器（这里是外层的ConstraintLayout）给Surface的最大可用高度，也就是屏幕高度，因此Surface的wrapContentHeight()会适配子元素的请求，最终高度变为全屏。

使用height(IntrinsicSize.Min)时适配内容的原因 #

height(IntrinsicSize.Min)会强制触发固有测量流程：父容器会先主动查询子元素的「固有最小高度」——即子元素不使用任何多余空间、刚好能放下自身所有内容的最小高度，这个值由子元素的内容本身决定，和父容器传递的约束无关。
此时哪怕你给Column设置了fillMaxSize()，在固有测量阶段，Column也会返回自己实际内容需要的最小高度，而不是请求占满父容器，因此Surface的高度会被设置为这个值，和XML中wrap_content的效果一致。 #

两者的核心区别 #

• 测量逻辑不同
  • wrapContentWidth/Height 遵循常规测量流程，子元素的尺寸请求会受父容器传递的约束影响，如果子元素设置了fillMaxSize、weight这类依赖父约束的修饰符，会直接返回父约束的最大尺寸，导致父容器的wrapContent适配到最大可用空间。
  • width/height(IntrinsicSize.Min/Max) 走固有测量流程，父容器主动查询子元素内容本身决定的固有尺寸，不受子元素fillMax类修饰符的影响，拿到的是子内容实际需要的尺寸。
• 性能和适用场景不同
  • wrapContent 不需要额外的测量步骤，性能更好，适用于子元素不会请求占满父空间的场景，可以直接达到XMLwrap_content的效果。
  • 固有尺寸修饰符需要多走一次固有测量流程，性能开销略高，适用于子元素需要使用fillMax类修饰符，但父容器需要适配子内容实际尺寸的场景。

扩展小提示 #

如果你想要用wrapContentHeight也达到适配内容的效果，只需要把Column的Modifier.fillMaxSize()改为Modifier.fillMaxWidth().wrapContentHeight()即可，此时Column返回的高度就是自身内容的高度，Surface的wrapContentHeight会直接适配这个高度，不需要使用固有尺寸修饰符。

内容的提问来源于stack exchange，提问作者Ludiras