拆一个能跑通支付和地图的 Uber 克隆：全栈就该这么学

学全栈移动开发，最大的坑是什么？不是某个 API 不会用，而是不知道这些技术怎么串成一个完整产品。

你能找到一堆"React Native 入门"教程，也能找到"Stripe 支付集成"文档，但认证、地图、支付、数据库、状态管理怎么协作，这种端到端的实战，少见。

最近，一位开发者在 X 上推荐了一个开源项目：React Native + Postgres 的全栈 Uber 克隆，作者是知名编程教育品牌 JavaScript Mastery 的创始人。它把一个打车 App 该有的全做了：认证、实时定位、找车、支付、订单历史。

今天就来拆这个项目，看它为什么是学习现代全栈移动开发的标杆样本。

一、它是什么：一个真能跑的 Uber 克隆

这不是个 demo 玩具，是个功能完整的打车应用。能做的事涵盖了一个 O2O（线上到线下）产品的核心闭环：

用户侧功能

引导流程：首次注册的完整引导
邮箱密码 + Google OAuth 登录：双重认证，带邮箱验证
权限分级：乘客和司机的不同角色
首页实时定位 + Google 地图：打开就能看到自己的位置和地图标记
最近行程：一览历史订单
Google Places 自动补全：地球上任何地点都能搜索补全
找车：输入"从哪到哪"，系统找附近可用车辆
地图选车：在地图上直接选附近的车
确认行程：看到完整信息（时间、车费）再确认
Stripe 支付：卡支付、多支付方式
支付成功后下单：钱到了才创建订单
个人资料 + 历史记录：完整的用户中心
Android/iOS 双端适配

这套功能列表本身就是一份"做 O2O App 要覆盖哪些点"的清单。

二、技术栈：2026 年移动全栈的主流选型

这个项目的技术选型，几乎就是当前 React Native 全栈开发的"标准答案"：

层	技术	为什么选它
框架	React Native + Expo	跨平台，Expo 省掉原生配置地狱
路由	expo-router	基于文件的路由（类似 Next.js），告别手动导航配置
样式	Tailwind CSS（NativeWind）	原子化 CSS，开发快，样式一致
认证	Clerk	托管式认证，邮箱/OAuth/OTP 全套，不用自己写
数据库	Neon（serverless Postgres）	无服务器 Postgres，免费额度够学，按需扩
地图	Google Maps + Places + Directions	地图渲染、地点搜索、路线规划全套
支付	Stripe	全球支付标准，SDK 成熟
状态	Zustand	轻量状态管理，比 Redux 简单得多
动效	Reanimated + Gesture Handler	60fps 原生级动画
底部弹层	@gorhom/bottom-sheet	地图类 App 标配的底部抽屉

Uber 克隆技术栈分层：应用层、服务层、数据层

几个值得说的选择：

为什么是 Expo 而不是裸 React Native？ 因为 Expo 现在已经够强了：它把原生模块（定位、安全存储、本地认证、字体）都封装好了，不用折腾 Xcode/Android Studio。expo-router 还带来了 Next.js 式的文件路由，目录结构就是路由结构，开发体验远超老式的 react-navigation 手动配置。

为什么是 Zustand 而不是 Redux？ Zustand 是这几年的趋势：API 极简，没有 Redux 那一堆 boilerplate（action/reducer/store/saga），一个文件就能定义全局状态。对中小型应用，Zustand 的开发效率碾压 Redux。

为什么是 Neon 而不是 Supabase？ Neon 是 serverless Postgres：按需计费、自动休眠、分支数据库（像 git 分支一样给数据库开分支做实验）。它只管数据库，不管认证/存储，让 Clerk 和 Stripe 各司其职。这种"每个能力用最专的工具"的解耦，比 Supabase 的全家桶更适合学习每个组件。

为什么是 Clerk？ 自己实现邮箱验证 + OAuth + OTP + 会话管理是巨大的工程量。Clerk 把这些全托管了，几行代码接入，学习时省下的时间可以专注业务逻辑。

三、架构：基于文件的路由分组

打开 app/ 目录，你会发现它的路由组织非常清晰：用括号分组，把不同功能的页面隔离：

text

app/
├── _layout.tsx              # 根布局（Clerk/Stripe/字体初始化）
├── index.tsx                # 入口重定向
├── (auth)/                  # 认证组
│   ├── welcome.tsx          # 欢迎页
│   ├── sign-in.tsx          # 登录
│   └── sign-up.tsx          # 注册
├── (root)/                  # 主应用组（登录后）
│   ├── (tabs)/              # 底部 Tab 导航
│   │   ├── home.tsx         # 首页（地图+定位）
│   │   ├── rides.tsx        # 行程列表
│   │   ├── chat.tsx         # 聊天
│   │   └── profile.tsx      # 个人资料
│   ├── find-ride.tsx        # 找车
│   ├── confirm-ride.tsx     # 确认订单
│   └── book-ride.tsx        # 下单
└── (api)/                   # API 路由组
    ├── driver+api.ts        # 司机接口
    ├── ride/create+api.ts   # 创建订单
    └── ride/[id]+api.ts     # 订单详情

这个结构本身就是教科书：

(auth) / (root) / (api) 是路由组：括号目录不进 URL，只用于组织
认证页和主应用页物理隔离，权限边界清晰
API 用 +api.ts 后缀，expo-router 自动识别为后端接口（类似 Next.js API Routes）
(tabs) 嵌套在 (root) 里，形成"主应用内的 Tab 导航"

学会这个目录组织，你就掌握了 expo-router 的核心心智模型。

四、核心库的分工

lib/ 目录只有 4 个文件，但分工明确，值得学：

文件	职责
`auth.ts`	Clerk 的 token 缓存（用 expo-secure-store 安全存储）
`fetch.ts`	封装的请求函数，统一处理认证头和错误
`map.ts`	Google Maps 相关的辅助函数（距离计算、路径解码等）
`utils.ts`	通用工具（格式化、cn 类名合并等）

这套"lib 分文件"的组织，比把所有工具函数堆在一个 utils.ts 里清晰得多。每个文件对应一个领域，改地图逻辑只动 map.ts，改请求只动 fetch.ts。

状态管理：Zustand 的极简用法

store/index.ts 用 Zustand 管理全局状态，概念上大概长这样：

typescript

// 概念示意（非原码）
export const useStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  recentRides: [],
  // ...
}));

没有 reducer、没有 action type、没有 context provider 嵌套：一个 create 函数搞定。任何组件 useStore(s => s.user) 就能拿到状态。这种极简，是 Zustand 能取代 Redux 的根本原因。

五、这个项目最值得学的东西

拆完代码，我认为它最大的学习价值不是"Uber 怎么做"，而是这几样：

1. 端到端的产品思维

它不只是教你怎么写组件，而是教你怎么把认证、地图、支付、数据库串成一个完整业务流。这种"串联"的能力，是看 100 个单点教程都学不到的。

业务闭环长这样：

text

注册/登录（Clerk）
   → 定位授权（expo-location）
   → 地图显示位置（Google Maps）
   → 搜索目的地（Places Autocomplete）
   → 找附近车辆（Neon Postgres 查询）
   → 确认订单（计算车费）
   → 支付（Stripe）
   → 写入订单（Postgres）
   → 历史记录展示

打车业务闭环：从注册登录到行程历史的九步流程

每一步都涉及一个独立的技术领域，但它们必须无缝衔接。 学会这种衔接，就是学会了"全栈"。

2. 现代 React Native 的工具链

expo-router 的文件路由
NativeWind 的 Tailwind 样式
Zustand 的状态管理
Reanimated 的动画
Clerk 的托管认证

这套组合就是 2026 年 RN 开发的主流姿势。 学会它，你做任何 RN 项目都能直接套用。

3. Serverless 数据库的实战

Neon 的 serverless Postgres 是个新趋势：不用管服务器、按需计费、能开数据库分支。这个项目演示了怎么在前端直接用 @neondatabase/serverless 连接查询（通过 HTTP 协议，不走传统 TCP 连接池）。这种"前端直连 serverless DB"的模式，对小项目和原型开发极其友好。

4. 第三方服务的解耦组合

它没有用 Supabase 全家桶，而是：

Clerk 管认证
Neon 管数据
Stripe 管支付
Google Maps 管地图

每个能力用最专的工具，通过清晰接口组合。 这种解耦架构，比全家桶方案更灵活、更易替换、也更适合学习每个组件本身。

六、怎么跑起来

准备 API key

你需要 4 个第三方服务的 key：

Clerk：clerk.com 注册，拿 publishable key
Google Maps：Google Cloud Console 开启 Maps SDK + Places + Directions，拿 API key
Stripe：stripe.com 拿 publishable key + secret key
Neon：neon.tech 建数据库，拿连接串

安装运行

bash

git clone https://github.com/adrianhajdin/uber.git
cd uber
npm install

# 配置环境变量
cp .env.example .env
# 编辑 .env，填入上面 4 个 key

# 启动
npm start
# 然后按 i 开 iOS 模拟器，或 a 开 Android，或用 Expo Go 扫码

仓库里还带了一个 uber_assets.zip（2.8MB），里面是车辆图标等素材，README 里有解压说明。

数据库初始化

README 的 "Snippets" 章节有完整的 SQL 建表语句（drivers、rides 等表），复制到 Neon 的 SQL Editor 执行即可。

七、谁该学，怎么学

强烈推荐，如果：

你想学 React Native 但不知道从哪下手
你有前端基础，想扩展到移动 + 全栈
你想做有支付/地图/定位的 App，但没串过完整流程
你想了解 2026 年 RN 的主流技术栈长什么样

学习路径建议：

先跑起来：按 README 配好 key，在模拟器里完整走一遍下单流程。亲手点过一次"支付"按钮，比看 10 小时视频都有用。
读 app/ 目录：理解 expo-router 的文件路由分组。这是整个架构的骨架。
读 _layout.tsx：看 Clerk、字体、SplashScreen 怎么在根布局初始化。
读 lib/ 四个文件：理解认证、请求、地图、工具的分层。
改造一个功能：比如把"找车"逻辑改成按距离排序，或者加一个"收藏常用地址"。改一个真实功能，才算真正消化。
看配套视频：项目作者的 YouTube 频道（JavaScript Mastery）有完整的逐步教学，README 里有链接，适合边看边做。

八、诚实说几点

它偏教学，不是生产级。 比如 API 直接在前端调用（生产应该有 BFF 中间层）、Stripe 的 webhook 处理简化了、没有司机端的实时位置上报（真实网约车的核心难点）。学架构和流程极佳，但别直接拿去上线。

依赖较多，配 key 有点麻烦。 4 个第三方服务的账号都要注册，第一次配可能要一两个小时。但这是一次性成本，配好后开发很顺。

Expo 版本是 51：写文章时 Expo 已经有更新的版本，部分 API 可能有变化，跑的时候注意看警告。

没有司机端：这是个"乘客视角"的克隆，完整的网约车平台还需要司机端（接单、导航、收入管理）。但作为学习项目，乘客端已经覆盖了 80% 的核心技术。

九、小结

这是一个把认证、地图、支付、数据库、状态管理串成完整业务闭环的全栈 Uber 克隆，是学习 2026 年现代移动开发的标杆项目。

它最大的价值不在"Uber 怎么做"，而在让你看见一个真实产品是怎么由各种技术缝合起来的。这种"端到端的全局观"，是单点教程永远给不了的。

而且它的技术选型极其现代：Expo + expo-router + Zustand + Clerk + Neon + Stripe，几乎就是 2026 年 RN 全栈的事实标准。学会这一套，你做任何移动全栈项目都能直接套用。

如果你正想入门 React Native 或全栈移动开发，从这个项目开始，比从任何"入门教程"开始都值。

本文基于 X 平台上的公开推荐及 uber 仓库公开信息整理，仓库地址 https://github.com/adrianhajdin/uber ，配套教程见仓库 README。

延伸对照：桌面端的全栈范式可以用 Wails 或 Tauri 这类方案实现，与本篇的移动端全栈互相印证，两边都看过，主流全栈开发的形态就齐了。

字节笔记本