发现一个有趣的现象 ：几乎每个做 B 端产品的团队 ，都会在某个阶段收到用户强烈要求——"能不能在系统里加个多页签（Tab）功能 ？教训"听起来很合理 ，但真做起来才发现 ，千万签这事儿远比想象的端网多页复杂 。
先说说为什么 B 端用户这么喜欢多页签 。对他们来说 ，血泪这功能确实很实用 。教训想象一下 ，千万签你在处理订单的端网多页时候 ，需要同时查看客户信息 、页里引入库存状态 、个天还得填写发货单 。血泪如果没有多页签 ，教训就得不停地在不同页面之间跳来跳去 ，刚填到一半的表单因为跳转丢失了，又得重新开始 。
有了多页签就不一样了 ，几个任务可以同时进行，需要对比数据的时候也方便 ，整个工作效率确实会提升不少 。而且对 B 端用户来说，他们的工作本身就是多任务并行的 ，多页签正好符合他们的工作习惯 。
你可能会问 ，浏览器本身就有多页签功能 ，为什么用户还要求在网页内部再做一套 ？
这其实有历史原因。早期的 B 端用户大多是从 Windows 客户端软件开始接触办公系统的，那时候的软件特别喜欢用选项卡（Tab 的另外一个译名） ，像 Office 、各种 ERP 系统都是这样设计的。用户从年轻时就习惯了这种交互方式。
Windows 的选项卡
传统 ERP 软件的选项卡
关键是 ，Web 兴起的时候 ，浏览器市场的老大是 IE。老版本的 IE 浏览器 ，跟现在的 Chrome 、Edge 不一样，它自己没有多页签功能。你想同时看几个网页 ，就得开好几个 IE 窗口 ，既笨重又麻烦 。所以 ，当企业把软件从客户端搬到网页上时 ，用户就自然而然地提出要求 ："我以前的软件能同时开好几个窗口 ，你这个网页版也得做到 ！"怎么办呢 ？开发人员只能在网页内部手动模拟一套页签系统 。
老版本的 IE 浏览器
就这样 ，B 端网页内置多页签成了一种约定俗成的"标配"。
虽然现在 Chrome 成了主流 ，浏览器自带的页签功能已经非常强大 ，但用户的习惯一旦养成 ，就很难改变。对他们来说 ，浏览器是浏览器 ，工作软件是工作软件 。他们希望工作流的所有操作都在软件内部闭环 ，而不是跳到浏览器层面去管理 。这种习惯 ，或者说"肌肉记忆" ，就是他们强烈要求内置多页签功能的根本原因 。
B 端用户对"屏效"特别敏感 ，也就是屏幕的利用效率。他们的工作界面通常信息密度很高 ，需要展示大量的表格 、图表 、表单。
多页签虽然方便 ，但会占用一整条横向空间 。别小看这 30-40 像素的高度 ，对 B 端用户来说 ，本来能显示 10 行数据的表格 ，现在可能只能显示 8 行了；本来一屏能看完的表单 ，现在非得往下滚一下才行 。对于那些天天盯着数据大盘的用户来说，这简直是不能忍的 。
我见过有些用户为了节省空间 ，把多页签做得特别小 ，结果页签标题显示不全 ，用户根本分不清哪个页签是什么内容 。这就本末倒置了。
左图没有多页签，表格能多显示一行 ，而且界面看着也更简洁
加了多页签之后 ，整个页面的层级结构就变得复杂了 。
首先是视觉层级 。想象一下 ，一个典型的 B 端后台 ：左边是全局导航菜单 ，顶部是全局标题栏和用户信息 ，现在中间又插入了一个多页签栏 。这样 ，页签里的内容属于页签 ，而页签又属于全局菜单的某个功能 。这种层层嵌套会让整个界面看起来拥挤复杂 。设计师必须绞尽脑汁 ，用颜色、阴影 、分割线去区分这些层级关系，稍有不慎 ，整个页面就会显得杂乱无章。
然后是交互层级 。这个问题更棘手 。以弹窗为例，一个常见的"删除确认"弹窗 ，它应该归属于谁 ？
在普通的网页里，点击链接通常只有三种结果 ：
这三种方式场景明确 ，用户已经习以为常。
但一旦引入网页内的多页签 ，每个链接就必须面临灵魂拷问 。选择一下子增加到六种 ：
这意味着每次设计一个按钮或链接 ，你都要反复思考 ：到底哪种方式最合适 ？
为了简化 ，你可能会说 ："那我统一一下 ，所有操作都在 B 端网页里新开页签 ！"然而，这又会带来新的逻辑问题。以"列表页 → 新建表单页"流程为例 ：用户在新建页签里填完表单并保存后 ，正常逻辑是返回列表页并刷新 ，显示新建的数据 。而使用新页签后 ，你需要额外添加逻辑 ：保存成功后自动关闭新建表单页签 ，并通知列表页页签刷新。这些额外的处理逻辑不仅增加了开发成本 ，还容易引入Bug 。
每个页签 ，用户都希望它能"记住状态" 。看报表的页签 ，用户希望数据实时更新；填表单的页签 ，用户又希望它保持不变，即使他填到一半切换出去处理其他事 ，再回来时草稿也应原封不动地保留 。
要保存这些页签的状态（包括数据 、滚动条位置 、第三方库实例等） ，意味着它们都必须在内存中"活着"。开三五个页签或许还行 ，但如果用户开了十几个 、二十个呢 ？特别是那些包含复杂图表 、地图或引入多个第三方库的页面 ，内存占用会急剧增加 ，最终导致整个网页变得极其卡顿 ，甚至直接崩溃 。
你可能会说 ，浏览器自带的多页签不也开很多吗 ，怎么就没事 ？问得好 ！多页签技术其实是个天坑。
早期的 IE 没有这功能 ，后来像 Maxthon（傲游）这样的第三方浏览器虽然提供了 ，但也是常年被崩溃问题困扰 。现代浏览器能做到稳定，是因为它们背后是谷歌 、Mozilla 这些巨头投入了海量工程师，把浏览器本身做得几乎像一个操作系统一样复杂 。你想想 ，Figma 这种能和 Photoshop 媲美的复杂应用都能在浏览器里跑 ，你就知道现代浏览器的技术含量有多高了 。你自己在 B 端页面里再套一层页签 ，等于在 Windows 里再装个 Windows——技术债堆到火星，后期维护能让你头发掉光 。
左图是 Chrome 浏览器架构 ，右图是安卓系统架构。都挺复杂的
当你在一个已有页签功能的软件（浏览器）中 ，又嵌套了另一个有页签功能的应用（你的 B 端网页） ，冲突就不可避免 。
作为设计师 ，我们不能生硬地拒绝用户 ，而应该采取引导的方式。
①先认同 ，再引导：首先要充分肯定用户的需求。"您说得对 ，能同时处理多个任务 、快速切换且不丢失数据 ，这个需求非常重要 ！"
② 重新定义问题 ：然后将问题从"要不要加多页签"转化为"如何更好地实现多任务处理" 。"我们共同的目标是提升效率 ，那么多页签是唯一的或最佳的解决方案吗 ？让我们一起探讨更巧妙的方案。"
③ 拿出替代方案 ：针对具体场景 ，提供更优的解决方案 。
当然 ，有时候胳膊拧不过大腿 ，因为各种原因 ，这个功能你必须得上。那行 ，我们也要有专业的兜底方案 ，把坑填得平一点 。
说实话 ，B 端产品的多页签需求背后 ，往往反映的是信息架构的问题。如果用户频繁需要在多个页面间切换，可能说明我们的信息组织方式有问题。与其在技术上硬扛 ，不如从根本上优化信息架构和交互流程 。
总而言之，内置多页签是个“重型武器” ，看着很强大 ，但后坐力也惊人 。作为设计师 ，我们既要理解它为何深得用户欢心 ，也要清晰地认识到它背后的五大“天坑” 。最好的策略是引导用户使用更轻 、更巧的方案，如果实在不行 ，那就带上这份“避坑指南” ，小心翼翼地把它实现好吧。
作者 ：龙爪槐守望者
关注微信
