我的项目实战（一）- 优秀的路由配置、底部导航栏和首部组件

ETA8
94 阅读8分钟

在前端开发中，我们常常会面对这样的问题：如何构建一个结构清晰、性能良好、易于维护的 React 单页应用？今天，记录下我项目的第一步——底部导航栏（BottomNav）、页面头部（Header）和路由系统，深入剖析其设计思路、实现细节以及背后的工程考量。

这篇文章适合有一定 React 基础的开发者阅读。我们将不满足于“能跑就行”，而是探讨为什么这么写、有没有更好的方式、可能会踩哪些坑。

一、从需求出发：我们需要什么样的导航体验？

假设我们要做一个移动端 Web 应用，比如一个外卖或电商类平台。这类应用通常具备以下几个特点：

  • 使用底部 Tab 导航切换主要功能页（首页、订单、聊天、我的）
  • 每个页面顶部有标题栏，部分页面需要返回按钮
  • 用户未登录时访问某些页面应自动跳转到登录页
  • 页面加载不能太慢，尤其是首次进入时

这些看似简单的需求，背后涉及了多个关键技术点：组件通信、路由控制、权限拦截、懒加载优化等。

接下来，我们就从这三个核心模块入手，层层拆解。

二、底部导航栏的设计与实现

PixPin_2026-01-20_22-56-45.png

1. 功能分析

底部导航栏的主要职责是：

  • 提供全局入口，让用户快速切换主页面
  • 视觉上高亮当前所在页面
  • 点击后正确跳转，并避免重复渲染无意义操作
  • 支持登录态校验（如“我的”页面需登录）

2. 实现策略

我们采用 react-router-dom 的 useNavigate 和 useLocation 来管理路由跳转和状态判断。

const { pathname } = useLocation();
const navigate = useNavigate();

通过监听 pathname，我们可以判断哪个 Tab 当前处于激活状态，并动态设置图标的颜色和文字样式。这种做法比维护额外的状态更可靠，因为 URL 才是唯一真相源。

图标处理：为何使用 Lucide-react？

我们引入的是 Lucide 图标库，而非 Ant Design 或其他 UI 框架自带图标。原因如下：

  • 轻量按需：每个图标是一个独立组件，Tree-shaking 后只会打包用到的部分。
  • 风格统一：线条简洁，适配现代设计语言。
  • TypeScript 友好：类型定义完整，编辑器提示顺畅。

例如：

const Icon = tab.icon;
<Icon size={24} className={isActive ? "text-primary" : "text-muted-foreground"} />

这里将图标作为组件动态渲染，提升了代码复用性，也便于后期扩展更多 Tab。

路由跳转逻辑的封装

点击事件中做了两层判断：

if (pathname === path) return; // 防止重复跳转
if (needsLogin.includes(path) && !isLogin) {
  navigate('/login');
  return;
}
navigate(path);

这体现了两个重要思想：

  1. 防抖优化：避免用户频繁点击造成不必要的 re-render。
  2. 前置守卫机制：类似 Vue Router 的 beforeEach，在跳转前检查条件。

💡 小技巧：needsLogin 是一个配置数组，存放需要登录才能访问的路径。这种方式比在每个路由里写 requireAuth: true 更集中、易维护。

三、页面头部组件的设计哲学

PixPin_2026-01-20_22-59-11.png

1. 头部要解决什么问题？

  • 显示当前页面标题（可能过长需截断）
  • 支持返回按钮（历史栈回退 or 自定义行为）
  • 固定定位，不影响内容滚动
  • 兼容黑夜模式（dark mode）

2. 结构设计：语义化 + 弹性布局

我们没有使用 <header> 包裹整个结构然后居中内容，而是巧妙地利用绝对定位来处理左右两侧的按钮区域：

<div className="absolute left-4">...</div>
<h1 className="truncate max-w-[60%] text-center">...</h1>
<div className="absolute right-4 w-10"></div>

这样做有几个好处：

  • 标题始终居中，不受左右元素宽度影响
  • 左右预留空间一致，视觉平衡
  • 使用 truncate 和 max-w 防止长标题溢出
  • w-10 占位确保右侧即使无内容也不会偏移

返回按钮的默认行为设计

onBack = () => window.history.back()

这是一个非常实用的默认值设定。大多数情况下，点击返回就是浏览器后退一步。只有特殊场景才需要自定义逻辑（如关闭弹窗、退出表单编辑等）。

同时使用 Button 组件并设置 variant='ghost'，保证视觉轻量化，不喧宾夺主。

✅ 最佳实践建议：对外暴露 API 时，尽量提供合理的默认值，降低调用方成本。

四、路由系统的工程化思考

1. 为什么要用懒加载（Lazy Loading）？

想象一下，如果所有页面都在应用启动时一次性加载：

import Home from './pages/Home'
import Mine from './pages/Mine'
// ...

那么首屏 JS 包体积可能达到几百 KB 甚至 MB，严重影响加载速度。

而使用 React.lazy + Suspense 可以实现代码分割（Code Splitting）：

const Home = lazy(() => import('@/pages/Home'))

Webpack 会在构建时自动为每个 import() 创建单独的 chunk 文件，用户访问对应路由时才加载。

配合 Suspense fallback={<Loading />}，还能优雅展示加载状态，提升用户体验。

2. 布局组件的抽象：MainLayout

你是否见过这样的结构？

<Route path="/order" element={
  <>
    <Header title="订单" showBackBtn />
    <OrderPage />
    <BottomNav />
  </>
}/>

如果每个页面都这样写，不仅重复，而且难以统一修改（比如某天要加一个 footer）。

我们的方案是使用嵌套路由 + 布局组件：

<Route path="/" element={<MainLayout />}>
  <Route path="" element={<Home />} />
  <Route path="order" element={<Order />} />
</Route>

MainLayout 负责包裹公共 UI（Header、BottomNav），子路由的内容插入其中。这是 React Router 推荐的最佳实践之一。

📌 补充知识：Outlet 组件用于渲染子路由内容，类似于 Vue 的 <router-view>。

五、状态管理与权限控制

关于状态的管理 我们采用了 Zustand 这类轻量级状态管理工具，而不是 Redux。

const { isLogin } = useUserStore();

原因也很明确：

  • 更少模板代码
  • 不依赖 Provider 嵌套
  • API 简洁直观，学习成本低

对于中小型项目来说，Zustand 完全够用且高效。

结合路由守卫逻辑：

if (needsLogin.includes(path) && !isLogin) {
  navigate('/login');
}

这是一种简易但有效的“路由守卫”实现。它虽不如 Vue Router 的导航守卫那样精细（比如支持异步验证），但对于大多数业务场景已经足够。

⚠️ 注意事项：这种守卫只能防止主动跳转，无法阻止用户直接输入 URL 访问。真正的安全校验仍需服务端配合。

六、工程配置的艺术：alias 与路径优化

在我们的代码中大量使用了 @/ 开头的导入路径：

import { useUserStore } from '@/store/useUserStore';

这是通过配置 TypeScript 和 Vite 的路径别名实现的：

vite.config.ts

resolve: {
  alias: {
    '@': path.resolve(__dirname, 'src')
  }
}

tsconfig.json

"compilerOptions": {
  "baseUrl": ".",
  "paths": {
    "@/*": ["src/*"]
  }
}

这样做带来的好处非常明显：

  • 路径不再受相对层级影响（告别 ../../../../）
  • 重命名文件夹更安全
  • IDE 自动补全更准确
  • 项目结构更清晰

这也是现代前端项目的标配配置。

七、关于 shadcn/ui 的选择

我的选择是 shadcn，它不是一个传统意义上的组件库（如 Ant Design），而是一种可定制的、基于 Tailwind CSS 的组件生成工具。

你可以运行：

npx shadcn@latest add button

它会下载 Button 组件的源码到本地 components/ui/button，你可以自由修改样式、逻辑，而不受版本升级影响。

这种方式的优点在于：

  • 完全按需：只引入用到的组件
  • 深度定制：样式可改，行为可控
  • 无运行时依赖：最终只是普通 React 组件 + Tailwind 类名

缺点则是：

  • 初始配置稍复杂
  • 需要理解 Tailwind 的 utility-first 思想
  • 更新组件需手动拉取新版本代码

但对于追求极致控制力和性能优化的团队来说，这正是理想之选。

八、总结：我们在构建什么？

回顾整个架构，其实我们构建的不仅仅是一个底部导航或几个页面，而是一套可扩展的应用骨架（App Scaffold）：

模块解决的问题技术手段
BottomNav全局导航图标组件 + 路由联动
Header页面标题与交互绝对定位 + 默认参数
RouterConfig性能与结构Lazy + Suspense + 嵌套路由
State Management登录状态共享Zustand
Build Config工程体验alias + TS 路径映射

这套体系具备以下特质：

✅ 高性能：代码分割、懒加载、按需引入
✅ 易维护：结构清晰、职责分明
✅ 可拓展：新增页面只需添加路由，无需改动全局逻辑
✅ 专业感强：符合现代 React 开发范式

写在最后

技术没有银弹，但好的架构能让团队走得更远。今天我们从几个看似简单的组件切入，揭示了背后隐藏的设计权衡与工程智慧。

也许你现在的项目还用不上这么复杂的结构，但了解这些模式的意义在于：当你遇到类似问题时，脑子里已经有了答案的轮廓。

希望这篇文章能帮你把“会用”变成“懂用”，把“写出来”变成“写得好”。

如果你觉得有收获，欢迎点赞收藏，也欢迎在评论区分享你的路由设计方案 👇

📌 延伸阅读建议：

  • 《React Router v6 官方文档》
  • 《Zustand vs Redux Toolkit 对比分析》
  • 《Tailwind CSS Utility-First Philosophy 解读》

保持好奇，持续精进。共勉。

avatar
文章
阅读
粉丝