如果你在 Shopify 上开店，又一直被手机端的菜单困扰，那有一种很多大型电商 App 都在用的模式，值得借鉴。它的核心就是组合使用 Tab Bar 和 Slide Menu：让 Tab Bar 负责快速直达，让 Slide Menu 负责深入浏览。这篇文章要讲的，就是这两者如何协同工作，以及 FAB 在其中的位置。
我曾经经营过一家店，犯了一个很常见的错误：把所有东西都塞进一个汉堡菜单里，然后想当然地认为”顾客有需要的时候自然会点开它”。可现实是，顾客远没有我们以为的那么有耐心。
为什么单一一种菜单不够用
在手机上，顾客的行为会分成两类，界限相当清楚。
第一类顾客很清楚自己想要什么。他们进来是为了看购物车、搜索，或者回到首页。他们需要快速行动、直奔目标。
第二类顾客还没决定买什么。他们想在各个分类里逛一逛，看看有什么有意思的东西。他们需要一张完整的店铺”地图”。
一个菜单很难把这两类人都服务好。如果你把所有东西都塞进汉堡菜单，第一类顾客本来一次点击就能完成的操作，就得多走一步。Nielsen Norman Group 发现，把主导航藏在一个按钮后面，会让它比直接展示出来更难找到、用起来也更慢。反过来，如果你想把整个分类树都铺在屏幕上，第一类顾客又会被淹没，屏幕也会显得很拥挤。
解决办法不是二选一，而是分工。
Tab Bar 负责主要目的地
Tab Bar 是固定在屏幕底部的导航栏，通常放 4–5 个项目。它始终可见，所以顾客不用点击就能看到。
它放在底部并非偶然。根据 Steven Hoober 在超过 1,300 次用户观察中的研究，屏幕上约 75% 的操作是用拇指完成的。屏幕底部中间，正是单手握持手机时拇指最容易够到的位置。把重要的目的地放在那里，顾客点击得既准又快，出错也更少。
那么 Tab Bar 里该放什么？只放那些使用最频繁、需要最快到达的目的地。比如，对一家时尚服饰店来说：
- 首页
- 搜索
- 分类（或”商品”）
- 购物车
- 账户
五个项目刚刚好。再多，每个按钮就会被挤得很小、不好点；再少，又浪费了宝贵的空间。这里不是列出每个子分类的地方——而是放几扇最大的门。
Slide Menu 负责整个分类结构
Tab Bar 只有 4–5 个位置。但一家真正的店铺通常有几十个分类和子分类。它们该放哪儿？
这就是 Slide Menu 登场的地方。Slide Menu 从屏幕边缘滑出，可以容纳完整的多级分类结构。顾客想从男装切到女装，从上装切到下装，从一个系列切到另一个系列——Slide Menu 就是干这个的。
这种模式的妙处，在于 Slide Menu 的打开方式。你在 Tab Bar 上放一个”分类”项目或一个”更多”图标。顾客一点，Slide Menu 就滑出来。这样两个菜单就连接起来了：Tab Bar 始终在那里负责快速直达，同时也是通往 Slide Menu、进行深度浏览的那扇门。
有一个细节虽小却很重要：当你确实要用 Slide Menu 时，要用文字清楚地标注它，而不是只留一个孤零零的图标，并且把它放在顾客预期能找到它的位置。NN/G 建议使用标准的三横线图标，再配上文字标签，这样顾客就能猜到里面是什么。Slide Menu 本身并不糟——只有当你硬要让它同时承担 Tab Bar 和它自己的工作时，它才会变糟。
角色分工归根结底就是这样：顾客需要速度时，用 Tab Bar；想浏览全部时，打开 Slide Menu。这正是许多大型电商 App 采用的 Tab Bar 与 Slide Menu 的组合，在 Shopify 上也行得通，而且不需要做任何大刀阔斧的改动。
FAB：是补充，不是替代
FAB（Floating Action Button，浮动操作按钮）是一个圆形的浮动按钮，通常位于屏幕右下角，叠加在页面内容之上。很多人觉得它很好看，想用它来做导航。我的建议是：别这么做。
FAB 应该只保留给恰好一个动作——一个重要且会反复使用的动作。几个合理的例子：
- 一个客服聊天按钮，让顾客在拿不准的时候能快速提问
- 促销期间的”查看今日特惠”
- 在很长的商品列表页上的”回到顶部”
FAB 不该承担主导航的原因：它只是一个按钮。点击它之后，它得打开一个菜单——这就又回到了我们刚刚想要避免的”导航被隐藏”的模式。Tab Bar 在导航上做得更好，因为它始终可见、又有好几个位置。FAB 适合一个单一、明确的行动号召。
换句话说：Tab Bar 和 Slide Menu 负责”去哪里”，而 FAB 负责”做一件事”。别让它们互相踩脚。
为什么值得把这个模式做对
关心你手机端菜单，有一个很实际的理由。根据 Baymard Institute 的数据，平均购物车放弃率在 70% 左右，而在移动端更高，约为 80%。当顾客从菜单出发就已经很难找到方向时，他们往往还没想到结账就离开了。
页面速度也很重要。一个臃肿的菜单会拖慢加载、引发布局抖动。Google 为 Core Web Vitals 设定的”良好”门槛是：LCP 小于 2.5 秒，INP 小于 200 毫秒，CLS 小于 0.1。菜单越精简、越轻量，就越容易守在这些门槛之内。
还有一点需要权衡：App 的数量。一家 Shopify 店铺通常会安装很多 App，每多一个，就多一段在页面上运行的代码。如果一个菜单工具能在一处把 Tab Bar、Slide Menu 和 FAB 全部搞定，你就不必东拼西凑好几个独立的东西。
无需写代码就能搭出这套模式
这套组合模式难的部分在于配置。你需要一个专门给手机端的 Tab Bar，一个与之相连的 Slide Menu，可能还要一个用于 CTA 的 FAB——而这些都得彼此契合，又不能动到桌面端的版本。
这正是 Navi+ 想要解决的问题。你在一处就能配置好 Tab Bar 和 Slide Menu，单独为手机端设置，拖拽即可，无需写代码。手机端和桌面端的配置是分开的，所以桌面端依然用正常的 Mega Menu。换主题时菜单也会保持原样，而且经过优化，不会拖累你的 Core Web Vitals。
我想留给你的，不是某个具体的工具，而是分工这种思维方式：别让一个菜单包揽一切。让 Tab Bar 负责快速直达，让 Slide Menu 负责深度浏览，让 FAB 负责一个动作。你的顾客会更容易找到方向，而这往往就是让他们愿意停留更久的第一步。
本文是更大篇幅指南 移动端导航——为什么汉堡菜单正在过时，以及该用什么来替代 的一部分。