React 响应式导航栏实战：从汉堡菜单到无障碍

导航栏大概是每个前端项目里第一个被写出来的组件，也常常是写得最随手的那个：一个 flex 容器、几个链接，看起来就完事了。可一旦视口跨过手机屏幕，问题便接连冒出来——链接挤成一团、汉堡菜单点了没反应、键盘用户根本走不完一遍导航。本文以一个用 React 和 Tailwind CSS 实现的响应式导航栏为底本，把从「最小可用」到「生产级」之间的那些坎，逐一过一遍。

一、最小可用实现：一个状态撑起两套布局

这段实现只有三十来行，骨架如下：

import React, { useState } from 'react';
import { Menu, X } from 'lucide-react';

const Navigation = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <nav className="bg-gray-800 p-4">
      <div className="container mx-auto flex justify-between items-center">
        <div className="text-white font-bold text-xl">Logo</div>

        {/* 桌面端：水平链接 */}
        <div className="hidden md:flex space-x-4">
          <a href="#" className="text-white hover:text-gray-300">首页</a>
          <a href="#" className="text-white hover:text-gray-300">关于</a>
          {/* 服务 / 联系我们，写法相同 */}
        </div>

        {/* 移动端：汉堡按钮 */}
        <div className="md:hidden">
          <button onClick={() => setIsOpen(!isOpen)} className="text-white">
            {isOpen ? <X size={24} /> : <Menu size={24} />}
          </button>
        </div>
      </div>

      {/* 移动端展开菜单 */}
      {isOpen && (
        <div className="md:hidden px-2 pt-2 pb-3 space-y-1 sm:px-3">
          <a href="#" className="block px-3 py-2 rounded-md text-white hover:bg-gray-700">首页</a>
          {/* 关于 / 服务 / 联系我们，写法相同 */}
        </div>
      )}
    </nav>
  );
};

代码不长，但三个决策值得逐条拆开看：

一个布尔状态。 useState 里的 isOpen 是整个组件唯一的状态机：false 收起，true 展开。桌面端完全无视它，移动端按钮和菜单读取它。状态最少化，组件就没有多余的渲染分支，也不需要额外的 effect 去同步什么。

断点切在 md。 hidden md:flex 表示水平链接在 768px 以下隐藏、以上以 flex 排开；md:hidden 正好相反。同一份 DOM、两套呈现，由 CSS 断点决定谁出场——组件里没有任何一处去读 window.innerWidth。

图标随状态切换。 lucide-react 的 Menu（三横线）与 X（关闭）由三元表达式选择，点击后按钮形态跟着变，形成最基本的操作反馈。

还有一个原型阶段可以容忍、正式项目里必须处理的问题：桌面端和移动端各写了一份链接列表，是实打实的复制粘贴——导航项一改就要改两处，迟早改漏。正确姿势是把链接抽成一个数组（文案加路径），两处都用 map 渲染，配置一处维护，两套布局自动同步。

样式上，外层的 container mx-auto 负责让导航内容与页面主栏左右对齐，避免在大屏上贴到屏幕边缘；导航栏本体用深色底 bg-gray-800 配白字，悬停降为 text-gray-300；移动端展开项带 px-3 py-2 内边距和 rounded-md 圆角。触摸目标至少留到 40px 见方，这是移动端导航最容易省掉、也最不该省的细节。

二、断点为什么是 md

Tailwind 的默认断点是 sm 640px、md 768px、lg 1024px、xl 1280px。导航栏切 md 而不是 sm，是因为 640 到 768px 之间（大屏手机横屏、小平板竖屏）通常还放得下四个链接；可一旦链接涨到六七个，这个区间就开始挤。所以断点不是拍脑袋定的，它由「最长链接文案 × 链接数 + Logo 宽度」共同决定——实际项目里先按桌面菜单总宽估一下，再决定切在哪；链接更多的站点往往要切到 lg。

顺带一提语义：Tailwind 是移动优先的设计，无前缀的类是基础样式，md: 的含义是「从这个宽度往上生效」。所以 hidden md:flex 读作「默认隐藏，768px 起以 flex 显示」，写组件时先想清楚移动端长什么样，再逐级往上加桌面样式，思路会比反过来顺畅得多。

另一个容易踩的坑：不要用 JS 读窗口宽度来决定渲染哪套导航。服务端渲染时拿不到视口宽度，客户端首屏很容易与 HTML 不匹配；而 CSS 断点方案下，同一份 DOM 由浏览器自己决定可见性，天然规避了这个难题。「一套 DOM、两种可见性」是响应式组件的第一原则，Tailwind 的响应式前缀只是它的语法糖。

三、汉堡菜单不是免费午餐

汉堡菜单是移动端导航的事实标准，但可用性领域对它的批评从未停止，主要集中在三点：可发现性低，三横线是抽象符号，不少用户根本不点，带「菜单」文字标注的按钮打开率通常高于纯图标；多一次点击，高频入口被收进抽屉，每次访问都要多点一下；以及「眼不见心不念」，收起来的功能容易被遗忘。

更稳妥的做法是分级处理：导航项在四个以内时，移动端尽量直接平铺，或改用底部标签栏这一在移动端更主位的范式；五个以上才交给汉堡抽屉。搜索、登录这类高频操作留在导航栏本体上，只把低频页面收进去。若用汉堡按钮，至少补一个 aria-label="打开菜单"，别让读屏用户听到一个无名按钮。抽屉展开时还要锁住 body 滚动，否则手指在菜单里滑动时，背后的页面会跟着一起滚——这是移动端抽屉最常见的漏项。

四、上线前要补的四件事

上面的实现能跑，但离上线还有四步要走：

可访问性。 给按钮加 aria-expanded={isOpen} 让辅助技术感知开合；给 nav 加 aria-label="主导航" 以区别页脚导航。键盘上补两件事：按 Esc 收起菜单并把焦点还给按钮；菜单展开时焦点移入第一项。对比度别凭感觉——bg-gray-800 配纯白文字能过 WCAG AA 的 4.5:1 门槛，但换成浅色主题后，hover 用的 text-gray-300 就未必达标。

路由集成。 href="#" 的导航栏只能在原型里活。接上路由（React Router 的 NavLink 或框架的 pathname API）后，用当前路径生成 active 高亮——高亮当前页不是装饰，而是位置感的来源。移动端还有一个高频 bug：路由跳转后要主动 setIsOpen(false)，否则抽屉会盖在新页面上。

溢出与置顶。 链接一多，中间尺寸屏幕会出现「桌面放不下、移动没必要」的尴尬区间。常见解法有二：次级链接收进「更多」下拉，或让导航栏横向滚动。内容型站点建议再加 sticky top-0，配合滚动方向的显隐（下滚收起、上滚出现），能省出可观的阅读高度。置顶之后还有两件小事：给 z-index 立个约定（导航一层、下拉一层、弹窗再高一层），否则层叠关系会变成玄学；半透明背景配 backdrop-blur 的毛玻璃导航栏很流行，但要确认下层内容滚过时文字依然可读，而不是只在首屏截图里可读。

展开动画。 条件渲染是瞬间出现，观感生硬。给容器加高度过渡或位移即可平滑许多；用 transition 处理 height 时注意取实际内容高度，别写死 max-height——菜单项数量一变就会露馅。

收尾

导航栏的演进路径很典型：先用一个 useState 和一组断点类名做出「能用」，再依次补上可访问性、路由集成、溢出策略和动效，把它变成「好用」。这套断点思维并不只属于导航栏——页面网格、卡片列表、页脚的响应式布局，走的都是同一条路。如今 AI 生成这类基础组件只要几秒，可运行的骨架唾手可得；真正拉开差距的，是骨架之外的工程判断——断点切在哪、哪些入口值得常驻、键盘用户怎么走完一遍导航。这些判断没有模板，值得每个项目自己想清楚。