iOS MVVM架构中子视图用户交互的处理方案探讨

三种方案的优缺点拆解 #

方案1：子ViewModel直接处理点赞 #

• 优势：逻辑闭环，Cell和子ViewModel绑定紧密，无需上层转发
• 劣势：子ViewModel需要直接对接网络或数据层，不符合单一职责原则——它本应只负责Cell的展示逻辑，现在还要承担业务操作，极易变得臃肿；且点赞后的数据同步到父ViewModel（比如列表点赞数刷新）容易出现不一致，因为父子ViewModel可能各持一份数据副本，同步成本高。

方案2：子ViewModel传递意图给父ViewModel处理 #

• 优势：子ViewModel仅负责感知用户交互，传递抽象意图（比如“要给这条内容点赞”），不涉及具体业务实现，符合单一职责；父ViewModel统一管理业务逻辑（网络请求、数据更新、通知列表刷新），数据一致性有保障；同时子ViewModel依然承担视图的输入输出逻辑，契合MVVM的核心设计思想。
• 劣势：需要在子ViewModel中定义回调（闭包、Delegate均可）传递意图，增加了少量代码耦合，但这种耦合基于“意图”而非具体实现，可控性极强。

方案3：Cell通过代理/闭包传给VC，再转父ViewModel #

• 优势：子ViewModel完全专注于展示，逻辑极简；VC作为中间层转发，避免了父子ViewModel的直接耦合。
• 劣势：子ViewModel彻底失去处理视图交互的能力，沦为纯数据容器，违背了MVVM中ViewModel需绑定视图输入输出的核心原则；VC的职责会被放大，原本VC仅需负责视图生命周期和ViewModel绑定，现在要处理Cell的交互转发，当列表交互增多时，VC极易变得臃肿。

关于你困惑的解答 #

你认为第三种方案中子ViewModel只负责输出不负责输入，不符合MVVM常规设计，这个判断是准确的。MVVM的核心是ViewModel作为视图的“大脑”，既要提供数据供视图展示（输出），也要处理用户的交互操作（输入）。第三种方案把交互处理完全从子ViewModel中剥离，相当于将其降级为纯数据模型，浪费了ViewModel的设计价值。

最优方案推荐 #

优先选择方案2，原因如下：

1. 严格贴合MVVM职责划分：子ViewModel处理视图输入（感知点赞点击），将抽象意图传递给父ViewModel；父ViewModel负责具体业务实现和数据更新，子ViewModel同时承担输出逻辑（更新点赞状态、点赞数）。
2. 数据一致性有保障：父ViewModel统一管理列表数据源，点赞操作后直接更新数据，再通知VC刷新Cell，不会出现多数据源同步的问题。
3. 代码可维护性强：子ViewModel仅关注Cell相关逻辑，父ViewModel负责全局业务，分工清晰；后续修改点赞逻辑（比如添加防抖、埋点）仅需改动父ViewModel，子ViewModel无需调整。

如果你的项目中VC逻辑本就简洁，且列表交互极少，方案3也可作为备选，但长期来看，方案2的扩展性更好，更符合MVVM的设计初衷。

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