一、开篇：被忽视的导航组件如何影响全局效率

1. 开端

工作中需要从0开始设计一个后台管理系统，但是由于产品框架不明确，以及需要在设计页面的过程中增加或删减菜单。考虑到后期的增删改查及全局同步，所以将导航栏设置为组件。

但是在后期使用的过程中，发现简单的设置为组件并不能使其达到我想要的效果：全局同步更新以及灵活变动展开状态与数量、图标、文本内容。

当然我敢肯定是可以实现的！！因为大厂设计系统中的导航组件可以实现，所以..找了很多资料去寻找如何才能达到我想要的效果。

And，最终我发现一个问题：前期做法是对的，只是改动的时候没有在母组件中修改，所以无法同步。

同时在查找资料的过程中学到了很多新知识。

2. 问题本质

全局同步≠机械复制。

是的，对于我想要的效果没实现之前，笨办法就是每一个设计稿都复制粘贴修改一下。

除了类似于导航栏全局同步的需求，多端适配也是一个比较常见的问题了。这类需求的隐藏成本其实蛮大的，所以！学起来呀！！！

本文主要以MasterGo工具搭建B端侧边导航组件为例，从基础知识点开始详细讲解如何搭建设计系统。

二、需求溯源：为什么需要系统化导航设计

1. 现代应用的复杂场景

对于移动端来说，目前市场上的尺寸种类较多，虽然我们日常做设计稿的时候只需要设计一个尺寸，然后进行适配就可以了，但是我们也需要考虑到响应式导航的自动化适配方式。毕竟一致的导航结构、流畅的适配方式，都有助于用户使用产品。

尤其是近几年来，随着折叠屏设备的普及，移动端折叠屏适配也算是当前移动应用开发中的一个重要议题。作为设计师，如何在不同尺寸和形态的屏幕上提供良好的用户体验应当是我们所需要关注的焦点。

同时，Web端响应式布局的需求也是不可忽视的。比如在Arco Design System中，对于不同大小菜单宽度限制在160px到400px之间，可以通过拖动实现导航栏宽度的变化。小红书网页版也对不同的屏幕宽度进行了限制，最大尺寸时左侧导航栏右侧内容展示五列，尺寸较小时整体布局改为底部固定导航栏。

✨知识点：

响应式布局：根据设备、屏幕尺寸和分辨率，自动调整页面元素的大小、位置和显示方式，从而为用户提供优质浏览体验的一种技术。响应式布局的解决方案大致有流式布局、弹性布局、网格布局、媒体查询布局。

流式布局：借助百分比来定义元素的宽度，高度则按照内容自适应。如此一来，元素会依据屏幕宽度按比例缩放，从而保证在不同屏幕尺寸下布局的一致性。

弹性布局 Flexbox：弹性布局是一种一维布局模型，它提供了强大的空间分布和对齐能力。通过设置容器和子元素的属性，可以轻松实现元素的水平和垂直对齐、空间分配等。在figma工具中，可以使用Auto Layout实现。MasterGo工具中，可使用自动布局中的换行功能实现。

宫格/网格布局（Grid）：二维布局模型，可将页面划分为行和列，再把元素精准放置到网格的特定位置。它能实现复杂的布局，且易于控制和维护。

媒体查询布局：利用 CSS 的媒体查询功能，依据不同的屏幕尺寸和设备特性，应用不同的 CSS 规则，从而实现不同的布局效果。

自适应布局：根据不同设备的屏幕大小和分辨率，自动调整网页的布局和样式，以提供最佳的视觉效果和用户体验。自适应布局通常使用 CSS 媒体查询和其他技术来检测设备的屏幕大小，并根据不同的屏幕尺寸应用不同的样式规则，即需要为不同的屏幕尺寸设计和维护多个布局版本。自适应布局的解决方案大致有固定布局、流体布局、弹性布局、混合布局、栅格系统。

固定布局：在固定布局中，网页的宽度是固定的，通常以像素为单位。这种布局在特定的屏幕分辨率下看起来很完美，但在其他分辨率下可能会出现滚动条或元素变形的问题。不过可以通过结合媒体查询，针对不同设备设置不同的固定宽度，以实现一定程度的自适应。

流体布局：也称为流式布局，它使用百分比来定义元素的宽度，而不是固定的像素值。元素的宽度会根据屏幕的大小按比例缩放，从而在不同屏幕尺寸下保持布局的相对一致性。

弹性布局：使用相对单位来定义元素的大小和间距。这些单位是相对于父元素或根元素的字体大小而言的，因此当屏幕大小改变时，元素的大小会根据字体大小的变化而相应地调整。

混合布局：混合布局结合了上述几种布局类型的特点，根据不同的页面区域和设计需求，灵活选择使用固定布局、流体布局或弹性布局。

栅格系统：把页面划分成一系列等宽的列与行，形成规则的网格结构，再依据设计需求将页面元素放置于这些网格之中。

✨对于自适应布局与响应式布局的区别：

自适应布局是为不同尺寸的设备（如手机、平板、桌面）预先定义固定的布局版本，当检测到设备类型或屏幕尺寸时，加载对应的预设布局。

响应式布局是基于流式布局 + 媒体查询的布局，通过一个灵活的布局结构，随屏幕尺寸的变化实时调整元素的排列、大小和位置，实现 “一个布局适配所有设备”。

2. 高效协同的必选项

2.1. 动态导航栏

动态导航栏通常指的是具有交互效果和自适应功能的导航栏，能够根据用户的操作（如点击、悬停）或屏幕尺寸的变化做出相应的动态响应。

以B端后台的侧边导航栏为例，列举以下几个常见的实现痛点。

权限管理：B端后台管理系统通常有着比较复杂的权限体系，不同角色的用户可访问和操作的功能不同，侧边导航栏需要根据用户的角色类别精准展示其可访问的菜单。用户角色发生改变，侧边导航栏实时更新。要保证导航栏及时更新的同时，流畅准确的渲染相应的菜单。

多级菜单：后台管理系统的功能较多，对应的侧边导航栏包含多级菜单。想要实现多级菜单的展开、收起、定位功能，需要认真设计其布局与交互。尤其是在设计初期，考虑到未来的发展，可以采用模块化的设计方式，方便后期添加新的菜单。

交互体验：部分产品为了提供较高的用户体验，可能会在侧边导航栏中添加一些动画效果，例如菜单的展开与收起过程中的过渡动画。快速响应与流畅性是需要重点考虑的。

主题定制：不同的企业或用户对于B端后台的界面风格或配色有着不同的需求，这里就需要实现侧边栏主题的定制功能了。普遍是更改颜色或字体样式，部分产品也会涉及到布局或图标的更改。要确保在各种主题下导航栏都可以保持良好的视觉效果和可用性。

2.2. 设计走查

交付设计稿后需要检查是否有统一设计风格与样式，如若使用组件库就不需要担心这个问题了，且后续需要修改也可实现修改一处全局同步。同时，设计走查也是必不可少的。

设计走查可大致分为界面布局、色彩视觉、交互操作、信息呈现四个部分，以B端后台侧边栏为例，列举一些高频雷区：

界面布局：空间利用不合理，元素间距过大或过小，不同屏幕尺寸与分辨率的适配问题。

色彩视觉：色彩过多页面视觉杂乱，色彩对比度不足无法识别重要信息，色彩搭配不协调影响用户视觉体验。

交互操作：不同的交互方式需要用户适应新的操作习惯，同一类型不同场景下的交互行为不一致，菜单操作区域过小或不明显。

信息呈现：菜单层级过多或分类不清晰。重要信息不突出难以快速找到，内容在不同环境下显示错位。

三、设计系统核心要点

1. 原子化组件设计

原子化组件是基于原子设计理论的一种设计方法，指将界面设计和开发进行高度模块化和精细化拆分，其认为界面是由一系列最小的不可再分的原子元素组成，这些原子元素具有明确的功能和独立样式，我们可以通过组合这些原子元素来构建复杂的界面。

按照原子设计理论，对界面元素进行划分，可分为原子（Atoms）、分子（Molecules）、组织（Organisms）、模板（Templates）、页面（Pages）。

原子：构成界面不可再拆解的最基本元素，具有单一功能和明确样式，比如图标、文字、颜色。

分子：由一个或多个原子组成，有具体功能的组件，比如导航栏。

组织：由分子或原子组合成的复杂组件，比如登录注册流程。

模板：由原子、分子、组织组合而成，形成页面的基本结构，不包含具体的内容数据，比如导航栏、侧边栏。

页面：在模板的基础上，填充具体的内容和数据后形成完整的页面，是用户最终看到的交互实际页面，比如个人页面。

原子化组件构建法则是一种将界面设计和开发分解成最小可复用单元的方法。常见的原子化组件构建法则：单一职责、高内聚性、低耦合性、可复用性、可组合性、可维护性、语义化、遵循设计规范。

✨知识点：

组件化设计指将界面划分为多个独立可复用的组件，组件具有独有的功能与样式，且可以独立开发、测试与维护。原子化组件是组件化设计的细化，组件化设计涵盖的范围更广。

原子设计 Atomic Design是由 Brad Frost 提出的界面设计方法论，它将界面设计分解为不同层次的组件，从简单到复杂逐步构建出完整的界面，以提高设计的效率、一致性和可维护性。

Brad Frost官网：https://bradfrost.com/

Brad Frost演讲视频：https://vimeo.com/109130093?&signup=true#_=_

原子设计模式实验室：https://patternlab.io/

2. 自动化布局

在设计系统中，自动化布局（Auto Layout）是一种通过约束和规则自动管理界面元素位置与尺寸的技术，可实现响应式设计，适配不同屏幕尺寸和设备。

前段时间，Sketch发布新功能，终于支持自动化布局啦。

像Figma、MasterGo、即时设计这类在线工具都是一直支持自动化布局功能的，将元素编组后启用 Auto Layout，通过设置 “间距”“排列方式”“弹性尺寸” 实现动态布局。

其嵌套逻辑可以简单理解为：先为单个元素创建自动布局（比如按钮），再将多个按钮放入父级自动布局（比如按钮组），以实现层级化约束。

具体的自动化布局约束，例如水平排列、垂直排列、换行排列、水平间距、左右间距、上下间距，该如何设置或许是新手遇到的较大的问题。这里有个小妙招，就是先设想一下增加或减少内容的时候，希望页面如何变化。或者先创建固定尺寸的容器，然后在容器上添加自动布局。

举个例子：我希望我的按钮固定高度，宽度随着按钮文案变化，这时候就可以设置按钮高度固定，设定左右间距数值，水平方向选择适应内容。同理，整体页面的自动布局也是一样的。

3. 变体(Variants)

在设计系统中，变体指的是基于同一基础组件或元素，通过调整特定属性（如尺寸、颜色、状态、样式等）形成的不同表现形式。它们既能保持核心功能的一致性，又能满足多样化的使用场景需求，是提升设计系统灵活性和复用性的关键机制。

举个例子：变体=篮子，组件或元素=篮子里的蛋。我想要什么品种什么颜色的蛋，直接从篮子里挑选就可以了呀。

变体的核心作用：

统一与灵活并存：通过预设规则管理变体，避免设计混乱，同时支持场景化适配。

提升效率：减少重复设计，使用时可直接调用不同变体参数，而非重新构建组件。

变体的设计原则：

一致性：所有变体需遵循设计系统的基础规范（如间距、字体、圆角等）。

可维护性：通过组件库工具集中管理变体参数，便于后续统一更新。

场景导向：变体需对应真实使用场景（如不同设备、用户角色、业务流程），避免无意义的冗余设计，不然到时候只会成为一个庞大的垃圾。

四、标杆解析：大厂设计系统导航设计

1. Arco Design System（2.5.2）

1.1. 基本资料

官网链接：https://www.arco.design/react/components/menu

组件所在分类与命名：导航-Menu菜单

包含内容：顶部导航菜单、深色模式导航、缩起内嵌菜单、内嵌菜单、不同大小菜单、悬浮菜单、悬浮按钮菜单。

不同大小菜单宽度限制：160-400px

1.2. 基本组件

menu-icon/fold（菜单-图标/折叠）、menu-icon/unfold（菜单-图标/展开）

menu-icon/menu-submenu-arrow-down（菜单-图标/菜单-子菜单-箭头-向下）、menu-icon/menu-submenu-arrow-up（菜单-图标/菜单-子菜单-箭头-向上）、menu-icon/menu-submenu-arrow- right（菜单-图标/菜单-子菜单-箭头-向右）

1.3. 变体组件

vertical-menu-item/Put away（垂直菜单项/收起）➡️组件属性：悬停、选中、禁用；属性值：false、true

vertical-menu-item/1st-level（垂直菜单项/1级）➡️组件属性：选中、悬停、子菜单、展开、数量、分组、替换文本

.vertical-menu-item/group（垂直菜单项/组）➡️组件属性：悬停、选中、禁用、替换文本

vertical-menu-item/2rd-level（垂直菜单项/2级）➡️组件属性：选中、悬停、禁用、分组、数量、替换文本

pop-menu-item/1st-level（弹出菜单项/1级）➡️组件属性：选中、悬停、子菜单、展开、数量、分组、替换文本

.pop-menu-item/group（.pop菜单项/组）➡️组件属性：悬停、选中、禁用、替换文本

pop-menu-item/2nd-level（弹出菜单项/2级）➡️组件属性：选中、悬停、分组、数量、替换文本

menu（菜单）➡️组件属性：类型、数量、收起；类型：垂直（指侧边导航）、悬浮（指侧边导航的折叠icon）、水平（指水平导航）

1.4. 设计逻辑

侧边导航栏所包含的元素有菜单、子菜单、图标、文本，整体的状态包含垂直菜单展开状态与折叠状态，菜单的状态包含默认、悬停、选中、禁用。

除去以上必备内容，部分产品也会有不同风格或定制皮肤，例如暗夜模式、浅色模式。

侧边导航栏通常承载2-3级导航，用于展示主要功能模块。若内容较多，为避免将所有功能平铺，需要对内容进行逻辑分组，例如将用户管理、权限管理等组合为系统管理。

一级导航栏普遍为图标与文字组合，二级导航栏普遍为文字缩紧显示，三级导航栏普遍为进一步缩进，但目前我看到的使用三级导航栏的产品较少。

在侧边导航栏的页面设计时，导航栏内容较多时也可以使用分割线或空白区域区分不同功能模块，对于重要的菜单也可以置顶显示。

2. Ant Design 5.0

2.1. 基本资料

【设计】

官网链接：https://ant-design.antgroup.com/docs/spec/navigation-cn

所在分类与命名：设计模式➡️全局规则➡️导航

垂直导航较横向的导航更灵活，易于向下扩展， 且允许的标签长度较长。类目数量不限，可配合滚动条使用，适合信息层级多、操作切换频率高的管理性质的应用。

所在分类与命名：设计模式-探索➡️全局规则➡️导航

很多菜单时使用，建议菜单多于 6 项时使用；

可以承载多个层级，但建议 1-3 个层级；

企业级产品推荐使用侧栏导航，其可见性更好易于扫读，各菜单重要性受菜单排列顺序影响较小。

【组件】

官网链接：https://ant-design.antgroup.com/components/layout-cn

组件所在分类与命名：布局-Layout 布局

包含内容：

顶部导航菜单、深色模式导航、缩起内嵌菜单、内嵌菜单、不同大小菜单、悬浮菜单、悬浮按钮菜单。

设计规则：

一级导航项偏左靠近 logo 放置，辅助菜单偏右放置。

顶部导航（大部分系统）：一级导航高度 64px，二级导航 48px。

顶部导航（展示类页面）：一级导航高度 80px，二级导航 56px。

顶部导航高度的范围计算公式为：48+8n。

侧边导航宽度的范围计算公式：200+8n。

视觉：

12px、14px 是导航的标准字号，14 号字体用在一、二级导航中。字号可以考虑导航项的等级做相应选择。

组件概述：

Sider：侧边栏，自带默认样式及基本功能，其下可嵌套任何元素，只能放在 Layout 中。

2.2. 简介

侧边两列式布局。页面横向空间有限时，侧边导航可收起。

侧边导航在页面布局上采用的是左右的结构，一般主导航放置于页面的左侧固定位置，辅助菜单放置于工作区顶部。内容根据浏览器终端进行自适应，能提高横向空间的使用率，但是整个页面排版不稳定。侧边导航的模式层级扩展性强，一、二、三级导航项目可以更为顺畅且具关联性的被展示，同时侧边导航可以固定，使得用户在操作和浏览中可以快速的定位和切换当前位置，有很高的操作效率。但这类导航横向页面内容的空间会被牺牲一部分。

断点宽度 breakpoint width：xs: '480px',sm: '576px',md: '768px',lg: '992px',xl: '1200px',xxl: '1600px'

3. 命名规范深度解析

3.1. 前缀法则

前缀用于标识组件的使用场景、层级关系或复用范围，常见于大型项目或组件库中。例如iOS/Android、App/Web/Base。

Base前缀：作为原子组件的基础组件，不依赖特定业务逻辑，且可跨项目复用。

Web前缀：Web端专用组件，依赖浏览器的特性，包含特定的Web端交互逻辑。

App前缀：移动端专用组件，依赖移动设备特性，包含原生交互与触控操作逻辑。
iOS前缀：移动端苹果设备专用组件，例如顶部状态栏与底部Home条。

Android前缀：移动端安卓设备专用组件，例如顶部状态栏。

3.2. 语义化命名示例

语义化命名通过层级关系、功能描述和特性标签，清晰表达组件的用途与结构。

命名结构解析：Nav_Top_WithSearch=组件类型_位置或层级_特性或修饰词

常见组件类型关键词：

Nav导航，Header头部，Footer底部，Sidebar侧边栏，Card卡片，Modal模态框，List列表，Form表单，Button按钮。

常见位置或层级关键词：

Top顶部，Bottom底部，Left左侧，Right右侧，Main主内容区，Sub次级/子级。

常见特性或修饰词关键词：

WithSearch带搜索功能，Fixed固定定位，Collapsible可折叠，Responsive响应式，Dropdown下拉式，Gradient渐变样式

完整命名示例：

Nav_Top_WithSearch → 顶部带搜索的导航栏

Nav_Side_Collapsible → 可折叠的侧边导航

Form_Login → 登录表单

Form_Register_WithCaptcha → 带验证码的注册表单

Card_Product_Horizontal → 水平布局的产品卡片

Card_News_WithImage → 带图片的新闻卡片

 Layout_Main_Column → 主内容区列布局 

Layout_Footer_Fixed → 固定底部的布局

3.3. 命名规范的深层原则

想要找到合适的命名规范，我们需要先了解几个基本的命名方法。

1.驼峰命名法（CamelCase）

驼峰命名法起源于Perl语言。 在早期编程中，由于编程环境和工具的限制，开发者需要一种方式将多个单词组成的变量或函数名写在一起，且不使用空格或下划线，驼峰命名法因其清晰紧凑的特点被广泛接受。Perl语言普遍使用大小写混合格式，而Larry Wall等人所著的畅销书《Programming Perl》封面图片是一匹骆驼，“驼峰命名法”由此得名。后来，这种命名法被Java等语言广泛采用，逐渐成为更通用的命名方法。

格式：
大驼峰（PascalCase）：也可称为帕斯卡命名法，每个单词首字母大写，其余小写（如UserProfile、HttpRequest）。
小驼峰（camelCase）：首个单词小写，后续单词首字母大写（如userName、isLoading）。

2.蛇形命名法（Snake_case）

蛇形命名法的历史可追溯至 20 世纪 60到70 年代，当时编程语言（如 Fortran、C）和操作系统（如 UNIX）的文本处理能力有限，文件名和标识符通常要求使用全小写字母。为了区分由多个单词组成的标识符，开发者选择用下划线_连接单词，形成了类似 “蛇形” 的视觉效果。也可以将其称呼为下划线命名法（Underscore Case）。

同时还要注意区分小写蛇形（Lower Snake Case）与SCREAMING_SNAKE_CASE。

小写蛇形命名法强调所有字母小写的变体（如user_name），SCREAMING_SNAKE_CASE特指全大写的蛇形命名（如MAX_LENGTH），常用于常量或环境变量，也被称为 “大喊蛇形”。

格式：用下划线_分隔（如user_id、calculate_total）。

3.烤串命名法（Kebab-case）

烤串命名法的历史可追溯至 1990 年代 HTML 和 CSS 的诞生。由于 HTML 和 CSS 对大小写不敏感（早期浏览器处理不一致），开发者倾向于使用全小写字母，并通过连字符-连接多单词标识符。

也可以将其称呼为连字符命名法（Hyphen Case）、脊柱命名法（Spinal Case）、破折号命名法（Dash Case）、Lisp Case。

格式：单词全部小写，用连字符-分隔（如user-profile、error-message）。

4.匈牙利命名法（Hungarian Notation）

匈牙利命名法由计算机科学家查尔斯・西蒙尼（Charles Simonyi）在 1970 年代开发，他后来成为微软的首席程序员（Excel 和 Word 的早期开发者）。该命名法最初用于系统编程，尤其是在没有强大类型系统的语言（如汇编、早期 C 语言）中，帮助开发者快速识别变量的实际类型或物理意义。也可以将其称呼为Apps Hungarian（应用匈牙利命名法）、Systems Hungarian（系统匈牙利命名法）、反向匈牙利命名法（Reverse Hungarian Notation）、装饰性匈牙利命名法（Hungarian Applied to Everything）。

格式：在变量名前加类型前缀，后接描述性名称（如strUserName、intCount）。

以上四种命名法，目前较为常见是前三种命名法，那些大厂公开的设计规范文件中，多数使用蛇形命名法或者烤串命名法。不过我个人更喜欢使用蛇形命名法，视觉上更容易分辨不同的单词。

除了命名方法，还需要注意的一些命名规范原则：

一致性原则：

全局统一前缀和分隔符（如使用_或-）。

相同类型组件使用相同前缀（如所有导航组件以Nav_开头）。

最小必要原则：

避免冗余描述（如Button_Component中的Component）。

保持命名简洁，优先使用行业通用缩写（如Ctrl表示Controller）。

可搜索性原则：

命名包含足够信息，使用者可通过关键词快速定位组件。

避免使用模糊词汇（如Widget、Util）。

与架构对齐原则：

命名应反映目录结构（如components/nav/Nav_Top_WithSearch）。

设计系统中的组件名称要保持一致。

五、实战：从0到1构建导航系统

1. 需求分析

动手做之前，我们需要先了解到导航中需要呈现出来哪些内容。换言之就是需要我们与业务部分沟通，梳理后台涉及的核心业务场景，绘制业务流程图（起码在脑子里有个流程啊喂）。

其次，后台中不同用户角色可查看与操作的模块不同。可以通过了解角色的工作目标、操作习惯确定其权限范围。

最后根据调研结果确定导航风格与样式，开始动手。

2. 组件库搭建

2.1. 建立原子属性库

不同体量的组件库所包含的具体内容上会有所差异，但是大体上是差不太多的。

先创建基础元素：

颜色Colors

作为整个设计系统所使用的颜色，包括主色、辅助色、状态色、文字色等，确保设计的一致性以及后续的可维护性。由于使用到语义Token，所以需要由原子颜色开始，完善色阶。在命名方面可以按个人习惯处理，但要注意识别性与维护性。

字体Font

定义设计系统中所使用的字体族、字重、字号、行高等样式规范，为文字排版提供统一的标准。

阴影Shadows

定义设计系统中的阴影效果（非必选项），包括阴影的大小、颜色、偏移度、模糊程度等，为界面元素增加立体感。目前B端后台中，弹窗较多使用阴影。

圆角

定义设计系统中按钮、图片、卡片等的圆角像素。不同的圆角所呈现的风格不同。同时也需要注意多个卡片套用时，圆角数值使用同心圆更为美观。

图标Icon

包含设计系统中所使用的图标库，为界面提供清晰易懂的图形符号，增强用户的识别和操作体验。图标设计要统一风格与大小粗细，且具有强识别性。

元素状态Focus

定义用户在交互过程中元素所呈现的样式与效果，提高用户的操作可加性与反馈。普遍B端导航包含未选中、点击、选中、悬浮、禁用这五种状态。

页面布局

定义设计系统中的布局规则，统一页面设计的间距，提高整体稳定性与统一性。

2.2. 组合分子组件

本步骤指将多个原子组件组合成具有功能的独立模块。

侧边导航栏大致可拆分为以下几个类型的组件：

1.基础导航组件

导航项（Navigation Item）：最核心的组件，通常以文字 + 图标组合的形式呈现，每个导航项对应一个页面、功能模块或分类（如 “首页”“数据中心”“设置”）。可支持交互状态普遍包含默认态、hover态（悬停效果）、点击态（悬停后按下效果）、激活态（当前选中页）、禁用态（不可点击）。

分组标题（Group Title）：用于对导航项进行分类聚合，提升信息层级（如 “核心功能”“系统管理”“帮助中心”）。通常不具备点击交互，仅作为视觉分隔和说明。菜单较少时不会使用分组标题。

折叠 / 展开按钮（Collapse/Expand Button）：当导航项分组较多时，用于折叠或展开某一组导航，节省空间。图标多为箭头，点击后切换分组的显示状态。

2.辅助功能组件

搜索框（Search Box）：用于快速检索导航项或全局内容，尤其适用于导航项数量较多的场景（如大型管理系统）。通常包含输入框和搜索图标，支持实时联想或回车搜索。

用户信息区（User Profile）：展示当前登录用户的头像、用户名、角色等信息，常位于侧边栏顶部或底部。

可点击展开下拉菜单，包含 “个人中心”“退出登录” 等操作。

快捷操作按钮（Quick Action Button）：提供高频功能的直达入口，如 “新建”“消息通知”“帮助” 等，通常以图标按钮或悬浮按钮形式呈现。

3.交互与状态组件

分隔线（Divider）：用于区分不同功能模块或导航分组，增强视觉层次感（水平或垂直分隔线）。

徽章/小红点（Badge）：附加在导航项旁，显示未读消息数、更新提示等（如 “消息” 旁的红色数字 “5”）。

加载状态（Loading Indicator）：当导航项内容需要异步加载时，显示骨架屏或旋转图标，提升用户等待体验。

4.适配性组件

侧边栏切换按钮（Toggle Button）：用于在移动端或窄屏模式下隐藏 / 显示侧边栏（如汉堡菜单按钮），提升空间利用率。

响应式折叠菜单：在屏幕宽度较小时，自动将多级导航折叠为下拉菜单或抽屉式导航，保证交互流畅性。

2.3. 构建响应式模板

建立好以上组件，接下来就可以组合组件构建侧边导航栏的模板啦。

根据不同的布局方式，可将其分为以下几种模板样式：

1.按屏幕尺寸适配的核心模板

a.桌面端（≥1024px）：全展示模式

布局特点：固定或可折叠的宽侧边栏，完整显示导航项文字、图标、分组标题等所有元素。

核心组件：完整导航项（图标 + 文字）、分组标题 + 折叠按钮、用户信息区、搜索框（可选）

交互逻辑：支持 hover 展开子菜单、点击切换激活态，可手动折叠为 “仅图标模式”（节省横向空间）。

b.平板端（768px-1023px）：精简展示模式

布局特点：侧边栏宽度缩小，优先保留核心导航项，次要功能折叠或隐藏。

核心优化：部分分组标题隐藏，仅通过图标区分功能；子菜单默认折叠，点击父项才展开（避免占满屏幕）；可通过滑动手势收起 / 呼出侧边栏。

c.移动端（≤767px）：抽屉式 / 悬浮式模式

布局特点：默认隐藏侧边栏，通过触发按钮（如 “汉堡菜单”）呼出，覆盖在内容区上方。或将侧边导航栏改为固定底部导航栏。

核心设计：全屏抽屉式导航（占满屏幕高度，宽度约 80%），避免手指操作误触；导航项简化为 “大图标 + 短文字”，增强触控友好性；顶部添加 “关闭按钮”（×），支持右滑手势关闭；次要功能（如搜索、用户信息）移至导航顶部，便于快速访问。

2.按交互方式分类的响应式模板

a.固定 + 折叠切换模板

适用场景：桌面端为主，需兼顾窄屏设备的管理系统。

响应逻辑：

大屏：固定宽侧边栏（如 240px），显示完整内容。

中屏：点击 “折叠按钮” 后缩为 “图标模式”（如 80px），hover 时弹出完整文字提示。

小屏：自动隐藏，点击顶部汉堡按钮呼出抽屉式导航。

b.自适应宽度模板

适用场景：内容型网站（如博客、文档平台），侧边栏包含多级分类。

响应逻辑：

随屏幕宽度自动调整侧边栏宽度（如从 300px 逐渐缩至 200px）。

当宽度不足时，优先隐藏文字，保留图标 + 徽章（如消息通知的数字）。

超小屏时转为底部弹出式导航（避免遮挡内容）。

c.混合式导航模板

适用场景：功能复杂的 App（如电商后台、CRM 系统），需平衡导航完整性和屏幕空间。

响应逻辑：

桌面端：左侧固定侧边栏 + 顶部快捷导航。

平板端：左侧可隐藏侧边栏 + 底部标签栏（高频功能）。

移动端：抽屉式侧边栏 + 底部 Tab 栏（核心功能入口），两者联动（如点击 Tab 栏 “我的”，侧边栏同步定位到个人中心）。

✨响应式模板的设计要点：

优先级排序：移动端优先保留高频核心功能（如 “首页”“消息”“我的”），次要功能（如 “帮助中心”）可放入 “更多” 菜单。

交互一致性：不同设备上的导航项点击、切换逻辑保持统一（如激活态样式一致），降低用户学习成本。

过渡动画：侧边栏展开 / 收起时添加平滑动画（如滑动、淡入淡出），避免突兀的界面跳转。

六、结语

这篇文章拖拖拉拉的写了两个月...在找资料的过程中，发现了一个新的知识点「亚原子设计」，是由原子设计 Atomic Design的作者Brad Frost提出的，之后会去认真了解一下。

and，导航相关的知识点还有蛮多的没学明白，就没得写笔记了...

最后，end.

————补充————

大概亚原子设计=亚原子语义设计=语义设计=语义Token

亚原子微粒指原子的一部分，同时还有一个理论叫“亚原子语义学”。

Powered by Froala Editor