Compose组件是否需内置isVisible参数？求性能/代码规范层面依据

问题背景 #

我的同事在设计多数新Compose组件时，习惯添加isVisible参数来控制组件可见性，示例代码如下：

@Composable
fun SomeComponent(
   label: String,
   isVisible: Boolean = true
) {
  if (!isVisible) return;
  Text(text = label)
}

我认为这是受Android传统View体系中isVisible控制逻辑的固有习惯影响。

我个人更倾向于通过外部代码判断来控制组件调用，觉得这种方式可读性更强，示例如下：

if (isModeEnabled) {
   SomeComponent(label = "Mode enabled")
}

我想知道，除了风格或个人偏好外，是否存在性能或代码规范层面的论据，能够支持我的实现方式？尤其因为Compose组件本质是函数，这让我联想到在非Compose场景下，如下写法显得十分不合理：

fun sendMessage(
   email: String,
   body: String,
   shouldSend: Boolean = true
) {
  if (!shouldSend) return;
  // 发送消息逻辑
}

技术层面的支持论据 #

1. 代码规范：遵循单一职责原则 #

Compose组件的核心职责应该是渲染指定的UI内容，而控制组件是否被渲染属于调用方的决策范畴。给组件添加isVisible参数会让组件承担额外的逻辑判断职责，违背了单一职责原则——就像你举例的sendMessage函数，它的本职是执行发送动作，"是否发送"的判断理应由调用方决定，不该塞进函数内部。

从可读性和维护性来看，外部条件判断更直观：阅读代码时一眼就能明确"这个组件在什么条件下才会被创建"，无需深入组件内部才能发现提前返回的逻辑。

2. 性能：减少不必要的函数调用开销 #

虽然Compose的重组机制做了大量优化，但当传入isVisible = false时，依然会触发该Compose函数的调用：参数会被解析，函数体执行到判断语句才退出。

而通过外部if控制组件调用的话，条件不满足时SomeComponent的函数体根本不会执行，完全避免了这部分调用开销。在频繁重组的场景（比如列表项、动态UI切换）中，这类开销的累积会更明显。

3. 贴合Compose声明式UI的设计理念 #

Compose的核心是描述"应该显示什么"，而非"怎么控制显示"。外部条件判断的写法更贴合这个理念：直接声明"当isModeEnabled为true时，显示该组件"，逻辑清晰且符合声明式的表达习惯。

组件内部的isVisible判断属于命令式控制逻辑，把"是否显示"的决策隐藏在了组件内部，不符合Compose倡导的透明、直观的代码风格。

4. 规避潜在的逻辑冲突 #

如果组件内部有isVisible的提前返回逻辑，后续若要添加初始化逻辑（比如LaunchedEffect副作用、状态初始化）时，很容易出现疏漏：开发者可能忘记这些逻辑也会被isVisible条件跳过，导致隐藏状态下的必要逻辑未执行，引入难以排查的bug。而外部控制组件调用的方式完全不存在这个问题——条件不满足时，组件的所有内部逻辑都不会被触发。

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