Kotlin中Toolbar菜单项按Fragment切换显隐功能失效问题排查

• 流程时机完全错位：你现在的逻辑完全靠比对Toolbar标题字符串判断当前页面，但Fragment切换、Toolbar标题更新、onPrepareOptionsMenu回调三个流程没有强绑定，经常出现两种异常：要么onPrepareOptionsMenu执行时标题还没更新完成，判断拿到的是旧值；要么Fragment切完了系统根本没触发菜单重绘，onPrepareOptionsMenu压根不执行，菜单项一直停留在上一次的状态。
• 硬编码字符串判断的方案本身脆弱：后续只要给Home标题加了多语言适配、调整了文案，这套判断逻辑会直接失效，没有任何鲁棒性。
• 遗漏了菜单刷新的强制触发环节：很多人写完onPrepareOptionsMenu的逻辑就以为万事大吉，实际上系统会缓存菜单状态，Fragment切换时如果不主动通知系统重绘菜单，写在准备回调里的显隐逻辑永远不会被触发。

• 先打通菜单刷新链路：在你统一封装Fragment切换的代码块里，每次Fragment事务提交、页面切换完成后，立即调用invalidateOptionsMenu()，强制系统重新走菜单创建、准备的全流程，从根源上解决状态不刷新的问题。
• 替换掉不可靠的标题字符串判断：在MainActivity里维护当前可见Fragment的类型标记，Fragment切换时同步更新这个标记，在onPrepareOptionsMenu中直接基于这个标记设置菜单项可见性，示例代码如下：

  // MainActivity 内维护的标记变量
  private var currentVisibleFragment: Fragment? = null
  
  // 切换Fragment时的逻辑示例
  private fun switchFragment(target: Fragment) {
      currentVisibleFragment = target
      supportFragmentManager.commit {
          replace(R.id.fragment_container, target)
      }
      // 强制触发菜单重绘
      invalidateOptionsMenu()
  }
  
  override fun onPrepareOptionsMenu(menu: Menu) {
      super.onPrepareOptionsMenu(menu)
      val shouldHideSearchSort = currentVisibleFragment is HomeFragment
      menu.findItem(R.id.db_menu_search)?.isVisible = !shouldHideSearchSort
      menu.findItem(R.id.db_menu_sort)?.isVisible = !shouldHideSearchSort
  }
  

• 如果想进一步解耦代码逻辑，也可以利用Fragment自带的菜单关联能力：不需要在Activity层硬判状态，让所有ContentFragment调用setHasOptionsMenu(true)，在Fragment自身的onCreateOptionsMenu方法里把搜索、排序菜单项加载进Toolbar；而HomeFragment直接调用setHasOptionsMenu(false)，从根源上不参与菜单流程，自然不会展示这两个图标。
• 踩坑提醒：不要把菜单项的动态状态设置混在onCreateOptionsMenu里，这个方法只会在菜单第一次创建时执行一次，所有动态状态变更一定要放在onPrepareOptionsMenu里配合invalidateOptionsMenu触发，不然同样会出现状态不刷新的问题。

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