在最近一次代码审查中，我遇到了一类极具隐蔽性的典型问题：一些名为 UseCase 的类并不是按预期在“调用时执行”。而是在创建时即开始消费数据流。按理说，这让人一时难以察觉，却可能导致长期潜伏的严重 bug。说起来，

常见但有问题的写法

class FeatureAvailabilityUseCase(
private val repo: FeatureRepository,private val workerScope: CoroutineScope。) {
var isFeatureAvailable: Boolean = false
private set
init {
workerScope.launch {
repo.observeFeatureEnabled
.collect { enabled ->
isFeatureAvailable = enabled
}
}
}
}

这种写法在很多项目中都能见到，看起来功能没有问题：

• Repository 提供 Flow。
• UseCase 消费并转换状态。
• Scope 保证协程运行。

只是它悄悄改变了职责语义，让 UseCase 从业务执行单元变成了隐藏的后台任务。你可能已经无意中让某些模块永远保持活跃，却不知何时该停止！

再看主要问题，UseCase 不应该在构造阶段产生副作用

一个语义清晰的 UseCase 通常满足以下约定：

从典型实现方式来看。

suspend operator fun invoke: Result
fun observe: Flow

使用者痛点： - 在 UI 层无法准确判断 UseCase 是否已完成；- 当多处地方同时实例化同一 UseCase 时后台协程会堆叠，导致内存泄漏。

COLD Flow 被“隐式热化”

Repository 通常返回冷流：

fun observeFeatureEnabled: Flow

COLD Flow 的语义是“谁 collect，什么时候 collect 才真正开始”。但在 init 中立即 collect，就把生命周期强行交给了 UseCase：

• 数据生产链路在对象创建时启动。
• 订阅行为不再由 UI / ViewModel 决定。
• COLD Flow 的惰性被破坏成隐式常驻。

使用者痛点： - 开发者很难追踪到底是谁触发了收集；- 如果 ViewModel 被销毁，协程仍然继续跑，占用资源。

. 生命周期完全不透明

. 谁来 cancel？

workerScope.launch { ... }

• workerScope 是谁提供？其生命周期与 UseCase 是否一致？
• 当 UseCase 被释放时这个协程是否会自动结束？
• 这些细节往往只能靠约定，否则容易出现不可控行为。

使用者痛点： - 无法确定何时需要手动 cancel，导致资源浪费；- 隐藏的后台协程可能导致频繁 GC 或 OutOfMemoryError。怎么说呢，

. UseCase 的语义已经丢失

Pain Point 聚合：开发者易错与维护成本双重打击

• Noisy resource leaks – 隐藏占用资源导致性能下降。
• Mismatched lifecycle – 难以预测何时停止订阅。老实说，
• Difficult debugging – 没有明显错误日志。却出现卡顿或崩溃，说起来，
"
• Lack of observability – UI 无法订阅状态变化。只能主动查询，

更推荐的写法——保持纯粹 & 生命周期显式控制