ViewModel函数传入Fragment类型参数是否合规？会留存Fragment引用吗？

这种传局部Fragment参数的写法，既不符合架构规则的要求，也存在明确的内存泄漏风险，并不会因为“局部参数”的形式就可以豁免规范约束。

架构规则的适用本质 #

架构规范要求「ViewModel不得持有Fragment/Activity引用」，规则禁止的核心从来不是“有没有把引用存成ViewModel的成员变量”，而是禁止业务逻辑层和视图层实现产生强耦合：

• 从引用生命周期的字面定义看，如果frag只是方法内的局部临时变量，在方法执行完成、栈帧销毁后，这个引用确实会被正常回收，不会被ViewModel长期留存。
• 但只要这个引用被任何长生命周期的执行块（比如协程闭包）捕获，它就会突破局部变量的生命周期限制：协程没执行完，引用就不会被释放，和你把它存成ViewModel成员变量造成的泄漏效果没有本质区别。
• 部分开发者会误以为只要不把Fragment引用存成ViewModel的成员变量，就算局部参数传Fragment是合规的，本质上是误解了架构规则的设计初衷——规则的目的是让业务逻辑层完全不依赖视图层的具体实现，而不是仅做表面的形式合规。

当前实现的实际问题 #

你贴的代码存在两个核心硬伤：

• 明确的泄漏风险：代码里frag被viewModelScope.launch的协程闭包捕获，协程执行数据库IO操作期间，就算用户已经销毁了当前Fragment（比如快速返回页面、触发系统配置变更），Fragment实例还是会被协程引用攥住，直到协程执行完成才会释放，直接造成不必要的内存占用。
• 深度的架构耦合：ViewModel的方法签名直接依赖了具体的ManualAddCustomerFrag实现类，等于让业务逻辑层硬编码了视图层的具体实现细节，后续如果调整Fragment类结构、更换导航实现，ViewModel的代码必须跟着同步修改，完全破坏了分层架构的可维护性和可测试性——根本没办法脱离Android框架单独给ViewModel的校验、入库逻辑写单元测试。

合规的实现方案 #

导航跳转属于纯视图层的一次性操作，正确的解耦实现逻辑是把导航动作转成ViewModel向外抛出的一次性事件，由持有NavController的Fragment自己完成跳转：

1. 在ViewModel中定义UI事件的密封类，明确所有需要触发的视图操作，比如跳转添加成功弹窗的事件
2. 用SharedFlow这类支持单次消费的流把事件对外暴露，在完成校验、数据库入库的流程后发射对应跳转事件
3. 在Fragment的视图生命周期范围内收集事件，收到信号后自己调用findNavController()执行导航动作
   这种写法下ViewModel完全不持有任何视图层的引用，既从根本上杜绝了闭包捕获造成的内存泄漏，也实现了业务逻辑和视图实现的彻底分离。

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