汉堡菜单——屏幕角落里那三条堆叠的横线——可以追溯到移动网页的早期。那时候屏幕小、网速慢、设计选择也不多，把所有东西都塞进一个小图标后面，是一种省空间的合理做法。这本身没有错。错就错在，把它用在每一种场景里。
如果你经营的店铺有超过十个分类，移动端导航往往是一处悄悄流失营收、却很少有人注意到的地方。顾客用手机进店，他们想随便逛逛，但通往你各个分类的入口却藏在一个图标后面，得点开才看得到。这篇文章会聊聊为什么汉堡菜单在电商移动端力不从心，以及一些更实用的替代方案：Tab Bar、拇指可达区，还有如何把几种菜单搭配起来，去贴合人们实际握手机的方式。
- 汉堡菜单会隐藏用户最需要的路径。
- 拇指热区会把重要导航推向屏幕底部。
- Tab Bar 加 Slide Menu 通常是实用的移动端组合。
汉堡菜单在电商移动端真正的问题
最大的问题不是汉堡菜单不好看——而是它把你的导航藏了起来。顾客得先点一下，才知道里面有什么。这听起来是个微不足道的动作，但乘以成千上万次访问之后，就在”看见你的分类”和”看不见你的分类”之间拉开了一道真实的差距。
Nielsen Norman Group 测量过这件事。在一项覆盖六个网站、179 名用户的研究中，他们发现把主导航藏起来，会让人们注意到并使用它的概率降低近一半，同时还会拉长任务完成时间、加重体验上的难度感。这个结论在手机和桌面端都成立。
还有一个值得掂量的细节：那个三条线的图标，今天对大多数人来说已经很熟悉，但据 NN/g 的说法，它对所有人来说仍然算不上一目了然，尤其是对那些不太熟悉技术的用户。如果你的顾客并不都是年轻人，这一点值得记在心里。
在电商里，多走一步的代价比人们以为的要高。平均购物车放弃率大约在 70% 左右——Baymard Institute 基于 50 项研究给出的数字是 70.22%。其中大部分发生在结账环节，但通往结账的整段旅程也起了作用。这一路上的每一个小障碍，都会再甩掉几位顾客。而一个被藏起来的菜单，是最容易移除的障碍之一。
这并不意味着汉堡菜单总是坏的。对于一个简单的博客，或者只有几个链接的落地页，它依然没问题。麻烦在于，电商店铺很少会那么简单。
拇指可达区——理解人们是怎么握手机的
要知道菜单该放在哪儿，你得先理解人们是怎么握手机的。拇指可达区这个概念来自界面专家 Steven Hoober，他在真实场景中观察了 1300 多次交互之后提出了它。
核心发现很简单：手机上的大部分操作都是用拇指完成的。Hoober 记录到，大约一半的人是单手握着手机、全靠拇指去点的。而拇指有它的物理极限——有些地方能轻松够到，有些得伸一下，还有少数地方不换握法几乎够不着。
人们通常会把屏幕分成三个区域：
- 容易够到： 屏幕的底部和中部，拇指自然停留的地方。重要的操作就该放在这里。
- 要伸一下才够到： 屏幕靠中间的两侧，够得到，但得稍微费点劲。
- 难以够到： 顶部的两个角，通常需要换手或者用两只手。
现在再看一眼汉堡菜单：它恰恰位于顶部的角落——最难够到的位置。这意味着最重要的那个导航元素，偏偏被放在了拇指最够不顺的地方。手机屏幕越大，这段距离就越明显。
这正是把菜单移到底部的根本原因。不是因为底部”更好看”，而是因为底部落在了拇指自然可达的范围之内。一旦理解了这一点，接下来的种种设计选择就容易解释多了。
深入了解阅读完整指南 → 拇指可达区——理解人们是怎么握手机的
Tab Bar——最主要的替代方案
Tab Bar 是固定在屏幕底部的一条导航栏，上面始终显示着几个图标。如果你用过银行 App、打车 App 或社交网络，你对它早就不陌生了。首页、搜索、购物车、账户——每一项都有自己的位置，始终可见，始终在拇指能够到的范围内。
Tab Bar 的优势归结为两点：它本来就可见，而且伸手就能够到。顾客不必点开它就知道里面有什么。主要路径都明明白白摆在他们面前。而且因为它在底部，正好落进拇指可达区里容易够到的那一块。
有一条值得记住的经验法则：Tab Bar 最适合放 3 到 5 个项目。Google 的 Material Design 和 Apple 的 Human Interface Guidelines 都是这么建议的。一旦超过五个，点击目标之间挨得太近，拇指很容易点错。对大多数店铺来说，四个项目往往是那个舒服的平衡点。
两种做法的简单对比：
| 汉堡菜单 | Tab Bar | |
|---|---|---|
| 可见性 | 点开前一直隐藏 | 始终可见 |
| 屏幕上的位置 | 顶部角落（难以够到） | 底部（容易够到） |
| 适合承载的选项数 | 很多，以列表形式 | 3–5 个主要路径 |
| 最适合 | 次要的、不常用的项目 | 最重要的路径 |
切换到 Tab Bar 时有一点要留意：别让它拖慢页面或者让布局发生位移。Google 对 Core Web Vitals 设了相当明确的阈值——LCP 在 2.5 秒以内、INP 在 200 毫秒以内、CLS 在 0.1 以内。一条固定在底部的栏，如果加得不讲究，可能会引起布局位移（影响 CLS），也可能让页面变重。所以选工具的时候，优先选那些在意加载速度的。
这也正是 Navi+ 能帮上忙的地方：它用拖拽就能搭出一个 Tab Bar，无需写代码，可以为移动端单独配置，而且做了优化，不会拖累你的 Core Web Vitals 分数。
深入了解阅读完整指南 → Tab Bar——最主要的替代方案
组合使用 Tab Bar + Slide Menu
读到这里你可能会想：既然 Tab Bar 只能放 3–5 个项目，那其余几十个分类该往哪儿放？这是一个常见的误解。Tab Bar 并不取代你的整个导航——它只负责最重要的那些路径。
实用的做法是把几种菜单组合起来，各司其职：
- Tab Bar 放那 3–5 个核心路径：首页、分类、搜索、购物车、账户。
- Slide Menu（其实就是展开版的汉堡菜单）放剩下的——完整的分类列表、政策页面、联系方式。这些项目很重要，但并不是每次都要用到。
- FAB（悬浮操作按钮）用于某个需要突出的单一操作，如果你的店铺需要的话，比如客服聊天或快速加购。
这样看来，汉堡菜单并没有被抹掉——而是被赋予了恰当的角色。它的职责是承载次要信息，而不是扛起整个导航。主要路径下移到 Tab Bar，拇指轻松够到，眼睛也立刻看到。
这种组合棘手的地方，在于必须为移动端和桌面端分别配置。在桌面端，铺开成好几列的 Mega Menu 依然合理，因为鼠标指针并没有”难以够到的区域”。但在移动端，同样这套菜单就会让人应接不暇。两种环境，两套不同的逻辑。
Navi+ 能在一个地方搞定所有这些菜单类型——Tab Bar、Slide Menu、Mega Menu、FAB、Grid Menu——并且让你为移动端和桌面端分别配置。菜单还会在你更换主题时保持原样，这样每次切换界面时你都不用从头重做。
深入了解阅读完整指南 → 组合使用 Tab Bar + Slide Menu（以及 FAB 的角色）
从哪里开始
如果只能先做一件事，那就用你自己的手机打开店铺，单手走一遍完整的购买流程。正常握着手机，别换手。留意拇指要伸多远才能进到一个分类里。
可以问自己几个问题来检查：
- 最重要的路径是不是一开始就可见，还是说你得先点开才能看到？
- 顾客要点几下才能进到他想要的分类？
- 最常用的那些按钮，是不是都在拇指舒服可达的范围内？
- 菜单加载时会不会拖慢页面或者让布局发生位移？
单手测试用手机打开店铺，不换手走一遍购买路径。
你不必一次性把所有东西都重做。通常，只要把那 3–5 个主要路径下移到 Tab Bar，再把其余的归拢进 Slide Menu，就足以感受到区别了。这是那种花费很小、却直接触及移动端顾客日常体验的改动。
汉堡菜单不是敌人。对于次要的、不常用的项目，它依然有一席之地。但在今天这样以移动端为先的店铺里，让它扛起整个导航，已经不再是最好的默认选择了。把重要路径从汉堡菜单挪到 Tab Bar，是你能为店铺做的最便宜、最值得的改进之一。
探索更多主题
本指南链接到一系列专题文章——逐一深入了解。