如何在Jetpack Compose中实现架构整洁的登录界面？

核心问题结论 #

针对你提到的架构问题，直接给出明确结论和落地方案：

问题1：取消LocalUser的ViewModel继承，手动逐层传递给控件是否可行？ #

• 技术层面可以运行，但属于非常差的实现方案，完全不推荐。
  手动逐层传递状态类会带来三个无法规避的问题：一是代码耦合度极高，后续任意层级的Composable调整都要修改传参链路；二是配置变更（屏幕旋转、深色模式切换）时，非ViewModel托管的类会直接重建，已经存储的用户资料、登录流程状态会全部丢失，需要额外手写大量状态保存代码；三是后续写单元测试时，这类强耦合的传参逻辑会大幅提升测试成本。
• 你碰到的ViewModel不能持有Activity和Google SDK需要Activity的矛盾，根本不需要通过放弃ViewModel来解决，正确的分层方式完全可以规避这个问题：
  1. 把LocalUser继续作为ViewModel实现，只负责持有用户状态、处理登录业务逻辑、对外暴露UI状态和操作事件，全程不接触任何Activity引用
  2. 将需要依赖Activity的Google SDK调用逻辑全部放在UI层：在Composable中通过rememberLauncherForActivityResult注册Google登录的结果合约，监听ViewModel发出的「启动Google登录」事件时，直接在Composable作用域内获取Activity调用SDK启动方法
  3. 拿到SDK返回的登录凭证（IdToken等）后，再把凭证传回ViewModel，由ViewModel完成后续的Firebase认证、状态更新逻辑
     这套实现完全符合ViewModel的使用规范，不存在间接持有Activity的问题，也是目前Compose整合Google登录的主流实现方式。

问题2：Composable持有Activity引用是否符合开发规范？ #

• 要根据持有方式和生命周期区分，不能一概而论：
  • 把Activity实例作为全局变量、成员变量长期存储，或者传入ViewModel/单例中持有，绝对违反开发规范，会引发严重的内存泄漏，配置变更后还会持有已销毁的旧Activity实例，导致崩溃、资源无法释放等问题。
  • 在Composable的作用域内，通过LocalContext.current获取当前上下文并转换为Activity实例，仅在Composable生命周期内临时使用（比如注册ActivityResult、启动页面跳转、调用需要Activity的SDK接口）是完全合规的，Compose官方提供的大量原生API本身就采用了这种实现方式，不会产生泄漏——当Composable绑定的视图层级销毁时，对应的临时引用会被正常回收，不会长期留存。

架构边界提醒：不要为了省事把所有登录逻辑全部堆在Composable中，那样会彻底破坏分层架构，导致业务逻辑和UI强绑定，后续无法进行单元测试。只要守住「需要Activity/系统权限的SDK调用放在UI层，业务逻辑、状态存储放在ViewModel层，两层之间通过单向数据流通信」的边界，就不会出现你碰到的架构矛盾。

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