Jetpack Compose可组合函数传参：传数据类还是多参数更合理？

“向Composable传入非State的普通数据类，对象变化触发重组就是不良实践”这个说法本身站不住脚。
重组是Compose刷新UI的原生机制，只要参数变化确实对应UI需要更新的场景，触发重组完全是预期行为，根本谈不上“不良”。真正会引发性能问题的从来不是“传了普通数据类”，而是传入了编译器无法识别稳定性的对象，导致Compose没法判断参数是否真的变化，每次上层重组都强制当前组件重复重组，产生无意义的性能开销——这个问题和你是否把参数封装成类没有任何关系，哪怕你把不稳定的字段拆成单独参数平铺传入，一样会出现冗余重组。

回到你说的10~12个参数的场景，两种写法不存在绝对的对错，只看适用场景：

封装为数据类传入的写法 #

// 符合稳定性要求的参数类写法
@Immutable
data class ReusableCompParams(
    val param1: String,
    val param2: Int = 0,
    // ... 其余参数均用val声明，类型为稳定的基础类型/其他只读数据类
    val param12: Int? = 0
)

@Composable
fun ReusableComp(params: ReusableCompParams) {
    // 组件内部逻辑
}

• 性能表现：只要你写的Params类符合稳定要求（所有属性为val、无可变字段、属性类型均稳定，必要时加@Immutable注解给编译器提示），这种写法的重组触发逻辑和你把12个参数平铺传入完全一致——只有当Params内的属性实际发生变化时才会触发重组，不存在任何额外性能损耗。
• 优劣势：
  • 优势：参数逻辑强聚合，调用时不会出现同类型参数顺序传反的低级错误，后续新增、调整同组参数不需要修改函数签名，维护成本极低
  • 劣势：如果参数本身互相独立、可选值多，封装成类反而会让调用方每次都要构造类实例，灵活度下降
• 适用场景：10+参数属于强绑定的同组属性时（比如商品卡片的所有展示字段、用户信息块的所有业务入参），这是非常标准的生产环境写法，根本不是不良实践。要避开的坑只有一个：不要在参数类里塞var可变属性、可变集合、生命周期和Compose不一致的对象（比如Context、传统View实例），就不会出冗余重组的问题。

平铺所有参数到函数签名的写法 #

@Composable
fun ReusableComp(
    param1: String,
    param2: Int? = 0,
    // ... 平铺12个参数
    param12: Int? = 0
) {
    // 组件内部逻辑
}

• 性能表现：和传入稳定数据类没有区别，不存在“平铺参数就更不容易触发重组”的说法，只要参数里有不稳定类型，一样会有冗余重组问题。
• 优劣势：
  • 优势：可以充分利用Kotlin的命名参数、默认值特性，调用方只需要传自己需要覆盖的参数，灵活度高
  • 劣势：12个平级参数的可读性极差，调用时非常容易传混同类型参数，后续调整参数、修改默认值需要改动所有调用点，维护成本极高
• 适用场景：仅适合参数互相独立、可选参数占比极高的场景，且实际开发中不建议写超过6个以上的平级Composable参数，否则维护成本会快速上升。

完全没必要把传统View开发里的建造者模式硬套到Compose场景：Kotlin自带的命名参数、默认值语法已经覆盖了建造者模式90%以上的多参数配置能力，专门为了多参数写Builder类只会增加大量冗余模板代码，不符合Compose声明式开发的习惯。

• 如果10+参数是强绑定的同组业务/配置属性，直接封装为带@Immutable注解的只读数据类传入，可维护性远优于平铺参数，没有任何性能问题。
• 如果参数互相独立、可选占比高，也不要硬堆12个平级参数，可以把同类型参数分组封装：比如把样式相关参数封成Style类、内容相关封成Content类、回调相关封成Actions类，兼顾灵活性和可维护性。
• 永远不要为了“避免重组”刻意回避数据类封装：你需要做的是保证传入参数的稳定性，而不是把所有参数拆成零散的基础类型，后者除了增加维护成本，不会带来任何实际收益。

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