Jetpack Compose中ViewModel创建方式的疑问：两种写法的差异与禁用原因

两种写法的核心区别 #

• 默认参数写法：把hiltViewModel()作为Composable的默认参数，ViewModel的创建逻辑在调用这个Composable时执行（包括父组件重组触发的调用）。
• 内部初始化写法：在Composable函数内部直接创建ViewModel，创建逻辑仅在该Composable自身重组时运行。

为什么这两种写法都不推荐？ #

1. 默认参数写法的问题 #

Composable的参数每次调用都会重新计算，默认参数也不例外。尽管hiltViewModel()本身会从ViewModelStore返回同一个实例（绑定当前ViewModelStoreOwner的生命周期），但这种写法存在两个硬伤：

• 行为不透明：Composable的参数应是外部传入的清晰依赖，把ViewModel创建逻辑塞到参数里，会让其他开发者难以追踪ViewModel的来源，排查问题时效率极低。
• 生命周期绑定风险：比如在嵌套导航场景中，父Composable的ViewModelStoreOwner可能与当前Composable的不一致，默认参数中的hiltViewModel()可能错误绑定到父级生命周期，导致ViewModel提前销毁或生命周期混乱。

2. 内部初始化写法的问题 #

这种写法看似直观，但同样不符合最佳实践：

• UI测试受限：如果Composable自行创建ViewModel，测试时无法替换为Mock版本，没法模拟不同业务状态验证UI表现，直接限制了测试灵活性。
• 耦合性过高：Composable的核心职责是渲染UI，把ViewModel创建逻辑硬编码在内部，会让组件与特定ViewModel强绑定，后续无法复用该UI组件适配其他ViewModel实现。
• 违背依赖注入原则：合理的代码架构应遵循“依赖由外部提供”，组件自行创建依赖会打破这一原则，长期来看会大幅降低代码可维护性。

推荐的正确写法 #

让ViewModel从外部传入，Composable仅负责接收并渲染UI：

@Composable
fun MainScreen(viewModel: MyViewModel) {
    // 基于viewModel中的状态渲染UI
}

// 在宿主（如Activity或导航目的地）中创建ViewModel并传入：
@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    private val viewModel: MyViewModel by viewModels()
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MainScreen(viewModel = viewModel)
        }
    }
}

这种写法既保证ViewModel生命周期正确绑定，又让Composable保持纯净，测试、复用都更便捷。

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