Jetpack Compose中何时使用Modifier.then？其作用是什么？

核心设计目的 #

Modifier 本质是按顺序执行的元素链，链上的每个修饰符按调用顺序依次生效，顺序错了最终UI效果、交互效果都会出问题。
then 是Modifier提供的最基础的拼接方法，核心作用就是把两个已经存在的独立Modifier实例，按调用顺序严格合并成一条完整的Modifier链。我们平时写的Modifier.padding().size().clickable()这类链式调用，内部其实也是通过then完成的拼接，区别只是常规链式方法是直接构造新的修饰符元素拼到链尾，而then是接收一个现成的Modifier对象完成拼接。

典型使用场景 #

• 条件化追加修饰符逻辑
  当你需要根据状态判断要不要加某段Modifier、加哪段Modifier的时候，用then可以把逻辑收拢在同一条链里，不会因为来回赋值打乱Modifier的生效顺序，代码也更整洁：

  // 基础修饰符
  val base = Modifier.fillMaxWidth().padding(horizontal = 16.dp)
  // 根据状态拼接点击/非点击逻辑
  val modifier = base.then(
      if (enabled) Modifier.clickable { doAction() } else Modifier
  )
  

  要特别注意：拼接顺序完全对应生效顺序，比如你把padding写在then拼接的clickable前面，点击区域就不会包含padding范围，反过来就会包含，和直接写链式调用的顺序规则完全一致。
• 复用通用修饰符片段
  项目里总会有一堆重复的修饰符逻辑：比如统一的卡片圆角阴影、统一的列表item边距、统一的按压态效果，你可以把这些公共逻辑抽成独立的Modifier片段，在具体业务场景用then拼接专属逻辑即可，不用每次都重复写一长串重复代码：

  // 抽离全局通用的卡片样式
  val Modifier.commonCard: Modifier
    get() = this.shadow(2.dp, RoundedCornerShape(8.dp))
        .background(Color.White, RoundedCornerShape(8.dp))
        .padding(12.dp)
  
  // 业务页面使用时，拼接选中态边框逻辑
  Modifier.commonCard
    .then(if (isSelected) Modifier.border(2.dp, Color.Blue, RoundedCornerShape(8.dp)) else Modifier)
  

• 组合自定义修饰符
  写自定义Modifier的时候，如果已经有实现好的独立修饰符逻辑，不需要重复造轮子，直接用then按顺序把现有逻辑拼起来，再补充自定义的特殊逻辑即可，大幅减少重复代码。

避坑提示：不要为了用then而用then。如果是可以直接链式调用的常规修饰符方法，没必要硬拆成两个Modifier对象用then拼接，过度使用反而会降低代码可读性。

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