手风琴菜单：空间叙事与交互设计的界面决策

手风琴菜单这种东西，放在UI组件库里实在是不起眼。按钮、表格、图表都比它抓眼球，面试的时候也没人拿它来炫技。但真正在后台系统、移动端、表单页面上摸爬滚打几年之后，你会发现这小东西恰恰是信息架构里最关键的决策点之一。

手风琴菜单的核心，是通过一组垂直堆叠的面板，让用户点击标题后展开或收起对应内容。同一时间要么只保留一个面板展开，要么允许多个面板并存，界面就像手风琴一样一开一合。它解决的核心问题很朴素：在有限的空间里装下更多层级化内容，同时不让用户一进来就被铺天盖地的信息砸晕。

这篇东西不是从零开始的组件教程，而是我这些年做界面时对“手风琴菜单”这个组件从原理、选型、实现到调优的完整复盘。产品经理、UI设计师、前端开发，甚至偶尔兼职交互的运营同学，都能在里面找到对自己有用的那一段。

1. 手风琴菜单的本质：一次只讲一个故事的界面控件

1.1 数字界面的“空间挤压”问题

做界面的时间越长，越会发现一个残酷的事实：屏幕没有变大，但塞进屏幕里的东西越来越多。

十年前做一个后台系统，左侧菜单三四十个入口已经算复杂了。现在随便一个SaaS产品，光设置页面就能拆出账号、团队、权限、通知、账单、API密钥六七个模块，每个模块下又挂着十几个子项。如果你把这些全部平铺开，用户打开页面的第一反应不是“功能真全”，而是“我该点哪儿”。

这就是典型的空间挤压问题。物理空间不够，认知空间同样不够。人一次能处理的信息块是有限的，把几十个条目全部摊在用户面前，等于让用户在最迷茫的时候做最重的筛选工作。手风琴菜单在这里的价值，不是把内容藏起来，而是帮用户排一个先后次序。

1.2 “空间叙事”不玄乎：手风琴在管理哪三种空间

标题里提到“空间叙事大师”，听起来有点文艺，但落到实践里其实非常具体。手风琴菜单同时管理者三种空间，理解透这三层，你才算真正会用它。

第一层是物理空间。一个展开的面板会占据页面高度，再展开一个，页面就更长。手风琴的折叠特性让页面默认状态保持紧凑，这是它最容易被看到的价值。

第二层是认知空间。认知空间的管理比物理空间更重要。手风琴强制用户在当前聚焦一个主题，展开“订单管理”时，视线里只有订单相关的内容，不会被旁边的“库存预警”带跑。这种设计手法在交互设计领域有个专门的说法叫渐进式披露，本质上就是“先把关键信息给你看，你想深入再自己展开”。

第三层是时间空间。手风琴的展开和收起是一个动态过程，用户点击、等待动画、阅读内容，这个时间序列构成了界面叙事的节奏。所有内容一次性倾泻出来，用户是被动的；内容在手风琴里等待被展开，用户变成了主动探索的人。主动探索带来的记忆效果，远好于被动接收。

1.3 手风琴菜单的三种常见形态

日常开发中，手风琴菜单至少会以三种形态出现，很多人没有意识到它们其实是同一个组件家族。

第一种是标准的折叠面板，也是最正统的手风琴。常见于FAQ、帮助中心、移动端的个人中心页面。点击问题，答案展开；再点另一个问题，前一个收起。这种形态最接近乐器和手风琴的联动感。

第二种是侧边栏的多级菜单。顶部是一级导航，点击展开二级导航，有些还会再展开三级。很多后台系统的侧边栏本质上就是一个纵向拉长了的手风琴。

第三种是移动端的折叠卡片，通常会配合横向滑动使用。下拉筛选区域、底部弹出的抽屉、首页分类区块，这些场景里手风琴往往承担着“入口引导”的角色。

认识到这三种形态的重要性在于：很多设计决策并不是从零开始，而是“把侧边栏的展开逻辑统一到折叠面板的交互规范里”。一旦你在组件层面把它们视为同一类东西，后续的维护、测试、文档化都会轻松很多。

提示：在很多设计系统里，手风琴（Accordion）和折叠面板（Collapse）会被当作同义词。但在细节上，手风琴往往强调单开联动、一次只展开一组，而折叠面板更偏向多开独立。做组件选型时，先确认团队定义，再决定交互规则。

1.4 手风琴菜单和几个近亲控件的边界

手风琴菜单常被拿来和Tab、下拉菜单、树形控件作对比。用一个表格说清楚它们的边界：

画这个对比不是为了分高下，而是为了说明：手风琴菜单的真正优势区在于“纵向空间不够、需要解释性文本、并希望用户聚焦单一主题”的地方。如果你发现需求里需要用户频繁对比两个分组下的内容，那手风琴大概率不是最优解。

2. 选型判断：什么场景上手风琴，什么场景绕开走

2.1 三个最典型的“手风琴友好型”场景

做选型判断时，我的经验是先看内容结构，再看用户行为。

第一个适合手风琴的场景是FAQ和帮助中心。问答内容天然是垂直堆叠的，用户一次只关心一个问题的答案。而且FAQ条目通常长短不一，短的几行，长的能占满一屏，用列表平铺会让页面显得特别凌乱。手风琴把这些长短不一的内容收进去，页面就干净了。实测下来，FAQ页面用手风琴还能顺带实现一个隐藏功能：鼓励用户先看标题，再决定是否深入，降低了无效阅读率。

第二个场景是设置页面，尤其是移动端的设置页。iOS系统设置已经给了很好的示范——每个分组有明确的标题，点击进去看到具体选项，再点返回。Web端因为空间更大，往往不太需要用嵌套页面，但如果你有几十个设置项，全部平铺开用户会直接崩溃。把设置项按模块收进手风琴，保留每个模块的可见标题和当前状态摘要，用户扫一眼就能定位。

第三个场景是筛选器，这在电商和列表页特别常见。用户需要在一堆筛选项里“找品牌、找价格区间、找颜色”，每个筛选组有明确的类别名称。用手风琴把类别折叠起来，默认只展开最常用的品牌区间，用户按需点击其他类别。这里有个细节：筛选器里的手风琴通常建议允许多开，因为用户可能需要同时调整品牌和价格两个维度。

2.2 两类“绝对别用”手风琴的场景

有合适的场景，就必然有不合适的场景。我踩过最深的坑，是在一个需要对多组数据进行对比的后台页面里用了手风琴。

用户要做的是对比不同渠道的转化率，他需要同时看到渠道A和渠道B的数据。结果用了手风琴之后，他只能展开一个渠道，看完了收起来才能开另一个。那一刻用户在原地震惊了两秒，然后默默把鼠标移到浏览器刷新按钮上。这个教训让我记住一条铁律：任何需要“同时查看多个分组”的场景，都不要用手风琴，用Tab或平铺都比它强。

第二种不适合手风琴的场景是高频操作项。如果某个菜单项用户每天要点二十次，每次都要先展开、再点击、再收起，这个流程就是在折磨用户。手风琴的展开收起动画看似只有几百毫秒，但次数一多，累积起来就是可感知的延迟和烦躁。

SEO也是容易被忽略的一环。很多搜索爬虫在处理折叠内容时虽然比过去更智能了，但默认状态下不可见的内容在索引权重上仍然可能吃亏。如果你做的是内容站，又指望折叠里的关键词能被搜到，那需要谨慎处理，至少保证内容在HTML源码里是完整存在的。

2.3 一个真实的选型复盘：后台订单管理页的改造

分享一个我经历过的真实案例。前几年做一个电商后台的订单管理页，最初的版本把所有状态筛选、渠道筛选、时间筛选、导出按钮全部平铺在页面上。结果一个屏放不下，用户得滚动才能看到“查询”按钮，操作效率极低。

第一版改动用的是Tab，把“全部订单”“待发货”“已发货”“售后中”做成四个标签页。搜索结果确实清爽了，但产品经理很快发现一个新的问题：运营同学会同时关心待发货和售后中的数量，需要在两个Tab之间反复横跳，Tab切换的动画和重新加载让这个操作变得很碎。

后来我提了一个折中方案：顶部保留“待发货”“待退款”两个高频状态的数字角标，不让它们被手风琴收起来；其余的筛选维度全部收进手风琴里，默认展开时间范围，其他维度按需展开。这个方案上线之后，运营同学的操作路径从原来的“滚动找筛选栏”变成了“直接看到角标数字，点击进入对应列表”。手风琴在这里扮演了“收纳低频选项、突出高频信息”的角色。

这个案例让我对手风琴有了更深的理解：它不是一个简单的组件，而是一种对信息优先级进行编排的手段。关键不是要不要用手风琴，而是让哪些内容进入折叠——默认状态下的可见信息，才是真正需要被用户第一眼看到的。

3. 动手实现：一个好用且耐看的手风琴菜单是怎么做出来的

3.1 交互状态设计：从点击到展开，中间发生了什么

确定用手风琴之后，具体实现前的交互设计其实比多数人想得更细。

首先是状态定义。一个手风琴条目至少有四种状态：收起、展开、悬停、禁用。收起状态下，标题是唯一的可见元素，需要确保标题本身能说清楚内容主题。展开状态下，内容面板出现，同时标题区域的视觉样式通常会变化，比如背景色加深、图标旋转90度、文字加粗。

其次是图标设计。箭头图标旋转是最常见的做法，向右的箭头表示“未展开”，点击后旋转90度变成向下。要注意的是旋转动画的方向和角度不要做得太花哨，90度是一个既明显又有秩序感的幅度。还有不少团队会把“加号/减号”作为图标方案，用来暗示“更多/减少”的语义，这也是一种成熟的做法。

再次是默认展开状态。这里有个常见的纠结：到底让第一个面板默认展开，还是全部收起？我的经验是：如果第一个条目的内容被查看的概率显著高于其他条目，比如“商品基本信息”在商品编辑页的第一个位置，那默认展开是合理的。但如果所有条目被查看的概率差不多，或者页面本身依赖用户主动探索，那就全部收起，保持页面高度最小化。

注意：不要试图在用户点击一个条目时同时展开多个条目，除非你有明确的多开理由。单开模式下，用户一次聚焦一个主题，视觉负担最小；多开模式下页面容易失控，呈现出一堆展开面板互相挤压的状态。

3.2 从零手写一个手风琴菜单：HTML结构 + CSS动画 + JS状态

实现手风琴菜单的方式有很多种，最推荐的方式是HTML结构负责语义、CSS负责动画、JS只负责状态切换。三层各司其职，后面维护起来也轻松。

HTML结构上，每个条目应该包含一个触发按钮和一个内容面板，并且通过aria-controls和id把它们关联起来：

html复制<div class="accordion">
  <div class="accordion-item">
    <button class="accordion-header"
            aria-expanded="false"
            aria-controls="panel-1">
      <span class="accordion-title">订单信息</span>
      <span class="accordion-icon" aria-hidden="true"></span>
    </button>
    <div class="accordion-panel" id="panel-1" role="region">
      <div class="accordion-content">
        这里是订单信息的详细内容。
      </div>
    </div>
  </div>
  <div class="accordion-item">
    <button class="accordion-header"
            aria-expanded="false"
            aria-controls="panel-2">
      <span class="accordion-title">物流状态</span>
      <span class="accordion-icon" aria-hidden="true"></span>
    </button>
    <div class="accordion-panel" id="panel-2" role="region">
      <div class="accordion-content">
        这里是物流状态的详细内容。
      </div>
    </div>
  </div>
</div>

CSS动画部分，重点是展开高度的过渡。传统的做法是使用max-height从0过渡到一个足够大的值，但max-height的问题是动画时机不准——内容实际高度是120px时，你设定的max-height是1000px，动画会先快速展开到120px再继续空转，视觉上会出现“延迟感”。

现在推荐的做法是使用grid-template-rows，它可以让容器从0fr过渡到1fr，实现真正的自适应高度动画：

css复制.accordion-panel {
  display: grid;
  grid-template-rows: 0fr;
  transition: grid-template-rows 0.25s ease;
}

.accordion-item.open .accordion-panel {
  grid-template-rows: 1fr;
}

.accordion-panel > .accordion-content {
  overflow: hidden;
}

这个技巧利用了grid布局的一个特性：grid-template-rows的过渡动画可以作用于fr单位。配合子元素的overflow: hidden，内容就会被平滑地“撑”开。实测下来这是目前最干净的实现方案，不需要估算高度，也不会出现动画跳变。

JS状态管理也不复杂。单开模式下，每次点击一个标题，先关闭所有条目，再打开当前条目：

javascript复制const headers = document.querySelectorAll('.accordion-header');

headers.forEach(header => {
  header.addEventListener('click', () => {
    const currentItem = header.closest('.accordion-item');
    const isOpen = currentItem.classList.contains('open');

    // 先从所有条目上移除打开状态
    document.querySelectorAll('.accordion-item').forEach(item => {
      item.classList.remove('open');
      item.querySelector('.accordion-header').setAttribute('aria-expanded', 'false');
    });

    // 再切换当前点击的条目
    if (!isOpen) {
      currentItem.classList.add('open');
      header.setAttribute('aria-expanded', 'true');
    }
  });
});

如果你用的是React或者Vue，思路没有本质差异：父组件维护一个openIndex状态，点击标题时把它更新为当前条目索引，渲染时对比索引决定是否添加展开类名。

3.3 动效参数细节：时长、缓动、高度自适应动画

手风琴菜单的动效参数，是“外行看热闹，内行看门道”的关键细节。

动画时长是我反复调过的一个参数。展开时，内容出现的动画时长建议在200ms到300ms之间。低于200ms会显得生硬，用户还没反应过来动画就结束了；高于300ms会让用户觉得系统卡顿、节奏拖沓。收起时因为视觉期望是“快速关闭”，时长可以稍微短一点，设置在150ms到200ms之间比较舒服。

缓动函数方面，展开和收起都不要用线性动画。现实中物体的运动是有加速度的，展开时先快后慢，收起时先慢后快。常用的cubic-bezier(0.4, 0, 0.2, 1)是Material Design的标准缓动，表现稳重；如果你想要更有弹性的感觉，可以试试cubic-bezier(0.68, -0.55, 0.265, 1.55)，但注意这个弹性曲线在收起动画上很容易显得“抖”，慎用。

还有一个容易忽略的细节是展开时内容里如果有图片或异步加载的模块，动画会先撑开空间、图片后加载进来，导致视觉上出现空白闪烁。解决方案也不复杂：内容区域的图片提前占位，或者等图片加载完再触发展开动画。

4. 体验优化与避坑手册：那些踩过才记得住的细节

4.1 单开还是多开，这是个产品决策

很多人以为单开多开是一个实现细节，改一下JS逻辑就行。但往深了想，它本质上是一个产品决策。

单开模式更接近手风琴的原始语义——像乐器一样，一个音节只能对应一个键。它的优势是干净、聚焦，视线永远不会被两三个同时展开的面板拉扯；劣势是用户无法同时看两个内容块，对比型需求直接没戏。

多开模式则更灵活，用户可以自由组合展开的条目，适合设置页、筛选器这类需要多维度操作的场景。但多开的问题也很明显：当用户是一个爱随手展开的人时，页面很快就恢复到“全部打开”的混乱状态，手风琴的空间节省意义就失效了。

我的实践心得是：如果没有强需求，默认用单开模式。单开模式让用户每次只面对一个选择，决策成本最低。如果确实需要多开，至少提供“全部展开/全部收起”的快捷按钮，让用户有办法一键回到整洁状态。

4.2 内容懒渲染与预加载的取舍

手风琴菜单的一个隐藏问题：如果每个面板里都塞了重资源，用户不展开不代表这些资源不需要加载，至少从HTML源码层面，内容已经存在于DOM里了。

从性能角度看，如果手风琴面板数量不多、内容轻量，直接全部渲染进DOM是最简单的做法。但如果面板里有复杂的图表、长列表或者视频，就值得考虑懒渲染——用户第一次展开某个面板时，再去加载里面的数据。

懒渲染的实现逻辑听起来很高级，其实就是监听面板的展开状态：面板还没展开过的时候，内部显示一个加载占位；第一次展开时，触发数据请求并渲染内容。这里要留个心眼：用户反复展开收起的场景下，数据已经请求过一次，第二次展开应该直接展示缓存内容，而不是重新请求。

4.3 无障碍支持：键盘、读屏器和ARIA

手风琴菜单的无障碍支持，是国内开发环境里经常被忽视但实际很重要的一个内容。

键盘操作层面，手风琴的标题本质上是一组按钮。用Tab键可以逐个聚焦这些按钮，这没问题。但更规范的做法是用方向键（上/下）在标题之间切换焦点，按Enter或Space展开/收起当前面板。这个行为模式参考了ARIA设计模式里对手风琴的规范，和Tab标签页的导航逻辑类似。

读屏器支持层面，关键就是前面HTML示例里的那两个属性：按钮上的aria-expanded告诉读屏器当前是展开还是收起状态；aria-controls把按钮和面板的id关联起来。面板容器上的role="region"让读屏器把它识别为一个独立内容区域，同时配合aria-labelledby指向标题按钮的id，读屏器就能说出“订单信息，按钮，已折叠，双击展开”。

我把无障碍支持放在优化章节，是因为它做起来不难、效果提升巨大，但往往排不进第一轮开发。如果项目里已经用了我前面提到的ARIA属性，那这部分工作其实已经完成大半了。

4.4 手风琴菜单常见问题速查表

4.5 最后再分享一个小技巧

在我自己的项目里，手风琴菜单除了标准交互之外，还会多加一个小细节：让标题栏的hover状态明显一点，加一个背景色变化和左侧的竖线指示条。这个细节不复杂，但对可用性的提升很大——用户第一次用页面时，并不清楚哪里可以点，hover状态能在鼠标划过的瞬间告诉他“这里是可以展开的”。

另一个经验是：如果页面里同时存在多个手风琴组件，它们之间的展开状态不要互相影响。每个手风琴组件维护独立状态，避免用户在上面展开了一个面板、滚到下面发现另一个也变了，这种跨区联动几乎没有场景需要，只会让用户困惑。

做手风琴菜单这几年，我最深的一个感受是：一个好的交互组件，应该让人感觉不到它的存在。用户不会记得自己刚才点开的是手风琴菜单，他只会记得“我想找的那个设置，很快就找到了”。所有关于空间叙事的巧思，最终都隐没在流畅的交互背后，变成界面里最安静、也最稳妥的那一部分。