RecyclerView共用Adapter时如何仅在收藏页移除指定列表项

核心思路非常简单：不要在Adapter内部硬编码页面判断逻辑，把差异行为做成可配置的参数/回调，初始化Adapter时由对应页面传入即可，完全不需要新建第二个Adapter。
具体实现步骤如下：

• 改造Adapter构造函数，新增两个可配置参数，不要用instanceof判断Activity类型做硬耦合：
  1. 布尔值标记位isInFavoritesPage：用来标识当前Adapter是否运行在收藏页，默认值设为false，默认适配首页场景
  2. 状态变更回调onFavoriteStatusChanged：把收藏按钮的点击事件抛给上层页面，方便两个页面各自处理全局数据同步（比如更新本地数据库、全局收藏数据池）
     示例代码（Kotlin，Java逻辑完全一致）：

  class PostAdapter(
      private val context: Context,
      private val postList: MutableList<Post>,
      private val isInFavoritesPage: Boolean = false,
      private val onFavoriteStatusChanged: ((post: Post, newFavoriteStatus: Boolean, position: Int) -> Unit)? = null
  ) : RecyclerView.Adapter<PostAdapter.PostViewHolder>()
  

• 编写收藏按钮的点击逻辑，拆分通用逻辑和差异化逻辑：
  通用逻辑两个页面完全一致，不需要做区分：点击后同步切换CheckBox的选中状态（你已经给CheckBox绑定了心形白/红状态selector的话，UI会自动切换），更新对应Post实体类的isFavorited字段值，触发回调通知上层。
  差异化逻辑只在收藏页生效：如果当前处于收藏页，且点击后是取消收藏的状态，直接从当前Adapter绑定的数据源中移除对应条目，刷新列表即可。
  对应点击监听代码示例：

  // 在ViewHolder绑定数据的方法中设置监听
  favoriteCheckBox.setOnCheckedChangeListener { _, isChecked ->
      // 列表复用时adapterPosition可能为无效值，直接return避免崩溃
      val currentPos = adapterPosition.takeIf { it != RecyclerView.NO_POSITION } ?: return@setOnCheckedChangeListener
      val currentPost = postList[currentPos]
      // 通用逻辑：同步数据状态
      currentPost.isFavorited = isChecked
      onFavoriteStatusChanged?.invoke(currentPost, isChecked, currentPos)
      // 差异化逻辑：仅收藏页取消收藏时移除条目
      if (isInFavoritesPage && !isChecked) {
          postList.removeAt(currentPos)
          notifyItemRemoved(currentPos)
          // 刷新后续条目的位置，避免点击错位
          notifyItemRangeChanged(currentPos, itemCount)
      }
  }
  

• 两个页面初始化Adapter时传入对应配置即可：
  • 首页初始化时传入isInFavoritesPage = false，回调里只需要做全局收藏状态的同步（比如更新数据库），不需要处理列表移除逻辑
  • 收藏页初始化时传入isInFavoritesPage = true，回调里同样做全局数据同步即可，条目移除逻辑已经通过配置自动生效

踩坑提示：在onBindViewHolder里给CheckBox设置选中状态前，一定要先把onCheckedChangeListener置空，等设置完isChecked属性后再重新绑定监听，否则RecyclerView复用条目时会自动触发监听，导致收藏状态错乱、条目异常移除的问题。

如果追求更彻底的解耦，你甚至可以把移除条目的逻辑也放到回调里交给Activity自己处理，Adapter完全不感知任何页面相关的逻辑，纯做列表渲染和事件透传，后续再有第三个页面复用这个Adapter，只需要传入新的回调逻辑就行，不需要改Adapter内部代码。

这种场景下单独建Adapter绝对不是好实践，属于典型的重复代码坏味道。

• 两个页面的列表项布局完全一致，95%以上的逻辑都是通用的，拆成两个Adapter会导致后续维护成本翻倍：比如后续要改卡片样式、加点赞按钮、调整文本显示规则，两个Adapter都要改一遍，很容易出现漏改导致的bug。
• 正确的拆分原则是：只有当两个列表的布局差异超过30%、核心交互逻辑完全不同的时候，才适合单独创建Adapter；对于少量逻辑差异的场景，把可变的业务逻辑抽成可注入的配置/回调，保留一个通用Adapter才是更合理的做法，既没有代码重复，也能灵活适配不同页面的差异化需求。

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