企业官网建设流程全解析

1. 项目概述：从零到一做一个网约车App，到底是种什么体验

两年前我还在用别人的打车软件，后来因为项目需要，用React Native和Node.js从零搭了一套英驱（InDriver）、优步（UBER）克隆版应用，前前后后跑了三轮迭代，踩过的坑能写满一个备忘录。今天这篇就是把那段时间沉淀下来的东西做个系统复盘，从整体架构、数据模型、后端API设计到前端页面实现，再到那些网上很少有人说透的坑，一次性讲清楚。

先回答一个大家普遍关心的问题：为什么选React Native和Node.js这套组合，而不是用原生或者Vue加其他后端？两个原因。第一，React Native做跨平台App，一套代码同时覆盖Android和iOS，开发效率和维护成本都占优势，尤其对于中小团队做MVP验证产品，这是最划算的路径。第二，Node.js做后端，轻量、异步I/O能力强，搭配Socket.io做实时通信非常顺手，打车业务里司机位置上报、订单状态推送这类高频实时交互，Node.js的天赋点正好点在这上面。

这个克隆应用解决了什么问题？简单说，就是把打车业务的核心链路打通：乘客发单、司机接单、行程计费、在线支付、订单评价。市面上像Uber、InDriver这样的产品看起来很复杂，但其实拆开看就是一套"用户体系+订单流转+实时通信+支付结算"的组合拳，关键是理解每条业务线背后的数据怎么流转。

这套项目适合谁来参考？如果你是初学者，想用一个小而完整的全栈项目切入移动开发和后端开发，这套东西够你啃一阵子；如果你已经有两年以上开发经验，想快速上手完整的商业化业务逻辑，这里面关于订单状态机、实时定位推送、价格计算策略的设计思路，可以直接套用到同类业务里。

整个项目的代码规模，前端加后端大概是7000多行，不算大，但麻雀虽小，五脏俱全。下面从架构设计开始拆。

2. 整体设计思路：Uber和InDriver的克隆，核心到底在克隆什么

2.1 打车业务的本质：一套"状态机+实时事件"的流转系统

在做任何代码之前，我先把业务流程仔仔细细捋了一遍。打车业务表面看是"乘客叫车-司机接单-到目的地-付款"，但落到系统层面，本质是订单状态在不同角色之间传递事件的过程。订单状态机是整个后端设计的地基，这一层没设计好，后面所有接口都会写得很痛苦。

我的设计是这样：订单状态从pending（等待司机）→accepted（司机已接单）→arriving（司机前往接人点）→in_progress（行程进行中）→completed（行程结束）。特殊分支有cancelled_by_passenger（乘客取消）、cancelled_by_driver（司机取消）、timeout（超时未接单自动关闭）。

每个状态下定义"谁可以触发什么动作"。比如pending状态下，乘客可以取消，司机可以抢单，系统可以超时关闭；但一旦到了in_progress，乘客就不能随意取消了，司机也不能中途退出，只能双方确认或者走人工客服介入。这样设计的目的是避免并发操作导致状态错乱，比如乘客取消了，司机同时点了接单，如果没有状态机约束，订单就变成"既取消又接单"的脏数据。

InDriver和Uber的区别在于计费模式。Uber是平台统一定价，乘客下单时价格固定，司机端直接按系统给出的价格接单；InDriver是司机自主报价，乘客发单后，附近司机往这个订单上出价，乘客从中挑一个最合适的，价格更像一个"竞拍"过程。我在后端设计里用bid_price字段单独存储司机报价，乘客选择后把accepted_price写入这个字段，最终计费按它走。

2.2 技术选型背后的取舍，为什么不是Python或Java

技术选型这块我纠结过一段时间。最初考虑过Python的Django做后端，但最终选Node.js，核心原因是实时通信和前端同构。打车App里司机的实时位置要推送到乘客端，乘客发单要广播给附近司机，这类高频低延迟的消息交互用WebSocket方案最顺手，而Node.js生态里的Socket.io把断线重连、房间广播这些问题都封装好了。

另外一个隐藏优势是前后端语言统一。React Native是JavaScript/TypeScript，Node.js也是JavaScript/TypeScript，前后端共用一个类型声明文件，比如订单状态的枚举、用户角色的类型定义，一边改了另一边立刻能感知到。我实际编码的时候明显感觉这个优势很大，不用在面试官面前装，自己写的时候就知道省了多少重复定义的工作量。

后端生态选型上，我用的是Express作为HTTP框架，Socket.io做WebSocket服务，数据库用MySQL + Sequelize ORM（如果你更习惯PostgreSQL，逻辑完全一样，只是连接配置不同）。为什么不上MongoDB？打车业务的订单数据和用户数据之间有强事务一致性要求，比如余额扣款和订单状态变更必须保证原子性，MySQL这类关系型数据库的事务处理比MongoDB成熟得多。但位置历史数据这类非结构化数据，我反而用MongoDB存了一份，用于离线分析和轨迹回放，冷热数据分离是中型后端项目的标配思路。

2.3 模块划分：从乘客端、司机端到管理后台

前端部分我拆成了两个App外壳，一个乘客端，一个司机端，另外做了一个简单的Web管理后台。三个终端的代码放在同一个仓库里，通过目录区分，公共组件和API封装放在/shared目录下，避免重复代码。

乘客端核心页面：首页地图+发单入口、订单详情页（包含司机实时位置）、历史行程列表、支付页、个人中心。

司机端核心页面：实时订单大厅（附近乘客的订单列表）、报价弹窗（InDriver模式）、接单后的导航页（显示乘客位置和目的地）、行程计费页、收入统计页。

管理后台我做得比较轻，核心功能是订单列表查看、用户状态管理、异常订单人工介入。实际商用项目中管理后台的复杂度不亚于用户端，但作为克隆项目，能看见订单流转和用户数据就够了。

前端路由用React Navigation，状态管理用Redux Toolkit + RTK Query。RTK Query这个选择我当时比较满意，它把API请求状态（loading、error、success）都自动管理了，不用每个页面手动写一遍useState加useEffect来做网络请求，代码量能省掉将近三分之一。

3. 数据模型与后端核心实现：订单、用户、计费一张表也不能少

3.1 数据库表结构设计：六个核心表撑起整个业务

数据模型设计这块，我是先画了一张实体关系图，然后落成六张核心表：users（用户表）、drivers（司机表）、vehicles（车辆表）、orders（订单表）、bids（报价表）、wallets（钱包表）。

用户表：id、phone、password_hash、name、avatar_url、role（passenger/driver/admin）、status（active/banned）、created_at。手机号是唯一登录凭证，所以这在业务里是天然的唯一索引，同时配合后端的注册验证码逻辑。

司机表：id、user_id（关联用户表）、license_number、license_status（pending/approved/rejected）、current_location_lat、current_location_lng、online_status、rating、total_trips。这个表的关键点是司机和用户是一对一关系，但加了很多职业属性字段，不能全塞在users表里，否则乘客端查询也会被这些无效字段拖累。

车辆表：id、driver_id、plate_number、model、color、seat_count、insurance_expiry。车辆和司机是一对多的关系，一个司机可以绑定多辆车，但同一时刻只能有一辆车处于"启用"状态，这个用is_active字段来标识。

订单表：id、order_no（订单编号）、passenger_id、driver_id、pickup_lat、pickup_lng、pickup_address、destination_lat、destination_lng、destination_address、status、price_type（fixed/bid）、price、created_at、accepted_at、started_at、completed_at。订单表是整张业务网的交通枢纽，字段最多，索引也最多。order_no我用时间戳加随机数生成，格式类似202409151230450123，确保唯一。

报价表（InDriver模式专用）：id、order_id、driver_id、bid_price、status（pending/accepted/rejected）、created_at。这个表支持一个订单多个司机同时报价，互不冲突，关键查询是"某订单所有报价按价格升序排列"。

钱包表：id、user_id、balance、frozen_amount、updated_at。冻结金额和可用余额分开，是为了处理提现和代扣款时的并发一致性。

3.2 核心接口设计：后端把业务闭环串起来

后端接口设计遵循RESTful风格，按资源拆分。拿订单这条链路来说，核心接口有：

• POST /api/orders：乘客发单，参数是起点终点信息，返回订单对象。
• POST /api/orders/:id/bids：司机报价（InDriver模式），参数是bid_price。
• POST /api/orders/:id/accept：Uber模式下司机直接接单，或InDriver模式下乘客选中某个报价。
• PUT /api/orders/:id/status：司机更新订单状态（前往接人、开始行程、完成行程）。
• POST /api/orders/:id/cancel：取消订单。
• POST /api/orders/:id/payment：发起支付并完成结算。

每个接口都做了统一响应格式：{ code: 0, data: {...}, message: 'ok' }，非零code表示业务异常，前端拦截器统一toast提示。这个设计在调试阶段帮了我大忙，一看code就能知道是参数问题、token失效还是业务冲突，不用去翻日志。

具体到订单状态流转的后端实现，我在每个状态变更的service方法里都加了一层校验逻辑。比如接单接口，先检查订单必须处于pending且没有其他司机接单，然后检查司机没有正在进行中的订单，两个条件都满足才允许更新状态。这里有个我踩过坑的细节：并发场景下两个司机同时点接单，如果只靠代码里的if判断，两个人可能同时读到pending状态，同时通过校验，最后都写入成功，订单就挂了。解决办法是给订单表加一个version字段（乐观锁），更新时WHERE status = 'pending' AND version = 1，如果影响行数为0说明已经被别人抢了，返回"手慢了"。

3.3 计费策略：固定价格和司机报价的两种玩法

计费是打车业务最敏感的部分，方案要经得起测试。

Uber模式（固定价格）：后端在乘客发单时根据起点终点之间的距离、时长、时段动因和实时供需系数计算价格。我用的简化公式：price = base_fare + per_km * distance + per_minute * duration + surge_multiplier * base_fare。距离从高德地图的路径规划接口拿真实距离，不是直线距离，否则高峰期绕路会亏到家。供需系数我用了一个雏形逻辑：统计当前10分钟内某区域发单量和附近在线司机数量，比值超过阈值就上调系数，最高2倍。这套逻辑简单，但足够撑起一场业务演示。

InDriver模式（司机报价）：乘客发单时不指定价格，只填写"预估价格区间"作为参考。订单广播给附近在线司机后，司机端看到参考价，自己输入一个愿意跑的价格提交报价。乘客在订单详情页看到所有报价，按从低到高排列，选一个满意的点"选他"。这里的关键设计是司机之间互相看不到别人的报价，否则会出现恶意低价竞争，这个在后端查询接口做了处理，司机端只返回"我的当前报价"，乘客端才返回全量报价列表。

支付流程我走的是模拟钱包逻辑：用户充值到钱包，行程结束后从乘客钱包扣款，同时把扣除平台佣金后的金额打进司机钱包。平台佣金我用一个常量PLATFORM_COMMISSION_RATE = 0.2，也就是20%。扣款的时候要包在一个数据库事务里：乘客余额扣除、司机余额增加、订单状态更新，三步要么全部成功，要么全部回滚。事务是支付功能不可逾越的红线，这块我测试阶段专门造了"余额不足但仍能完成行程"的场景，确保事务能把状态回滚干净。

4. 实时通信与地图集成：网约车的两个"技术门面"

4.1 Socket.io打通司机与乘客的实时链路

打车场景下的"实时感"主要靠三条socket消息流支撑。

第一条：司机位置上报流。司机端每3秒把当前经纬度通过socket.emit('driver-location-update', {lat, lng, tripId})上报到服务器，服务器把这个位置存到Redis里（键值对结构，key是driver:location:{driverId}），同时转发到目标乘客的socket连接。乘客端的订单详情页接收这个消息，更新地图上司机的小车图标位置。选Redis存位置是因为它自带过期时间机制，司机下线之后位置记录自动消失，不用额外写清理逻辑。3秒的上报频率是"卡顿感和电量消耗"的平衡点，实测1秒一次太费电，5秒一次乘客端看到的小车有瞬移感。

第二条：订单广播流。乘客发单后，后端根据乘客起点坐标，查询附近3公里内所有在线司机，把订单信息推送到这些司机的socket连接。距离计算用Haversine公式，可以用Redis的GEO数据结构来算（GEOADD把司机位置写进去，GEOSEARCH查附近司机），比在MySQL里用where硬算性能好很多。司机端收到广播后，订单大厅列表实时弹出，点击后进入报价环节。

第三条：状态变更推送流。乘客选了司机的报价，后端除了更新数据库，还要通过socket给司机推送order-accepted事件，给乘客推送driver-assigned事件，把司机和乘客的socket连上同一个房间。这个我用了Socket.io的join(room)机制，以订单ID作为房间名，后面所有关于这个订单的事件都往房间里广播，比维护"谁在哪个页面"的状态简单得多。

连接鉴权这里有个要点：Socket连接要带上token，在连接回调里先校验身份，再允许创建连接。我是这样写的：

io.use((socket, next) => { const token = socket.handshake.auth.token; try { const payload = jwt.verify(token, process.env.JWT_SECRET); socket.userId = payload.userId; socket.role = payload.role; next(); } catch (e) { next(new Error('unauthorized')); } });

使用io.use中间件在每个socket连接建立前就完成身份校验，避免建立连接后才发现token失效的尴尬情况。我曾经在这个上面踩过坑——最初的实现是客户端发起连接后前端再emit('auth', token)校验，结果所有未认证的socket也占着连接数，高峰期资源被无效连接耗掉，后来看到线上监控的连接数异常才追出来这个问题。

4.2 地图组件的选型和集成过程

React Native环境下的地图方案，主流有三个：react-native-maps（Google Map）、react-native-amap3d（高德）、@burstware/react-native-baidu-map（百度）。我最后选了高德，原因很简单：在国内网络环境，Google Map的服务不稳定，高德的文档和社区更丰富。

集成过程说简单也简单，说坑也多。核心步骤如下：

• 在高德开放平台注册应用，创建Android平台和iOS平台两个Key，包名必须和App的实际包名一致。
• Android环境安装react-native-amap3d，在AndroidManifest.xml里添加权限声明：ACCESS_FINE_LOCATION（精确定位）、ACCESS_COARSE_LOCATION（粗略定位）、INTERNET（网络）。忘记加权限导致的后果是App不崩溃，但一直拿不到定位。
• 在android/app/src/main/java/.../MainApplication.java里注册高德SDK的初始化代码。
• iOS环境用CocoaPods安装依赖，然后在Info.plist里配置NSLocationWhenInUseUsageDescription，否则定位服务在iOS上会被直接拒绝。

地图API的封装我建议统一放到一个MapService里，把"定位-逆地理编码-路径规划-距离计算"都封装成Promise，上层页面只关心数据和回调，不直接碰地图SDK的底层API。这样做的好处是后续要换地图供应商，只改服务层，页面不用动。我在第二轮迭代时把底层从高德换过一次，页面确实一行没改，算是提前买了保险。

4.3 启动白屏问题：一个React Native新手绕不开的坎

热搜词里频繁出现"react native 启动白屏"，这个我太熟了。白屏发生的原因就几种，把可能的坑列出来排一遍，问题就定位到了。

第一种：JS Bundle加载失败。Android调试模式下App启动后需要等待Metro服务打包并推送JS Bundle，如果Metro没启动、端口被占用、手机和电脑不在同一局域网，都会卡在白屏。排查方法：看Metro终端有没有日志输出，没有输出就说明JS资源没请求到。真机调试时手机和电脑必须处在同一个WiFi网络下，并且要在开发者菜单里把Debug Server Host改成电脑的局域网IP，不是localhost——手机上的localhost指的是手机自己，这个错我犯过好几次。

第二种：原生端崩溃后只留白屏。React Native的加载流程是原生先启动，然后加载JS引擎，如果原生端某个库没有正确链接（最常见是高德SDK的so文件没配置对），崩溃后用户看到的可能是白屏。这时看adb logcat里的Android日志，会有一条FATAL EXCEPTION，顺着崩溃栈就能找到是哪个原生库的问题。有一个排查技巧：把README里的原生配置步骤重新完整走一遍，特别是MainApplication.java里的代码，经常初始化顺序错了导致SDK加载失败。

第三种：入口组件渲染卡死。代码里某个组件在render阶段抛异常，但没有设置错误边界（ErrorBoundary），整个页面直接白掉。这种情况在调试阶段最常见，因为React Native的默认行为是白屏而不是显示错误信息。解决办法是做一个全局的ErrorBoundary组件，捕获渲染错误后展示一个提示页面，至少用户能知道"出错了"，不是一片空白。

第四种：Release包资源路径问题。打包Release版时，要把JS Bundle打包进APK的资源目录，如果assets/index.android.bundle这个文件不存在或路径不对，Release版启动时会白屏。解决方案是在package.json的build:android-release脚本里先执行react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res，确保bundle文件先打包好再走Gradle构建。

这个白屏问题我前后花了将近一周才彻底摸透，结论是：白屏不是单一问题，而是一类"JS层无法正常启动"的症状集合，排查思路要按"网络资源获取（Metro连接）→ 原生层初始化 → JS层渲染异常"的顺序逐层排除，而不是瞎试。

5. 前端实现：从页面架构到Node.js环境搭建的关键细节

5.1 前端页面架构：四个核心页面的实现要点

乘客端首页是最复杂的页面，上面是地图，中间是发单表单，底部是"预估价格"和"呼叫车辆"按钮。实现上有几个关键点：

地图占满全屏作为底层容器，发单表单浮在上面用绝对定位遮罩。这个布局看起来简单，但真机上遇到键盘弹出遮挡输入框、地图手势冲突这些小问题，花了时间调优。解决方案是把发单表单放进一个半透明卡片组件里，点击卡片区域的输入框时自动隐藏地图的手势响应（pointerEvents: 'none'），让位给键盘输入。

订单进度页的核心是socket事件驱动UI更新。页面挂载时通过useEffect连接Socket到服务端，订阅driver-location-update事件，每收到一条新位置就把地图上的Marker坐标更新一次。这里要注意频繁更新Marker的渲染性能，React Native下地图Marker如果每秒更新一次，在低端安卓机上会出现明显卡顿。我的优化方案是做一个定时器：socket收到的每条位置消息先存到useRef里，然后以2秒的间隔从useRef取最新位置更新Marker，既保证展示连续性又避免渲染压力。

登录注册页用手机号+验证码的方式，验证码由后端发送（真实环境接阿里云短信或腾讯云短信，模拟环境直接返回console）。前端做一个60秒倒计时禁用重新发送按钮，这是行业标配交互，不做会被用户骂。

司机端的订单大厅页，核心机制是socket广播驱动列表刷新。后端广播新订单事件时带上订单基础信息，司机端收到事件后往列表顶部插入新卡片，同时列表按"距离终点距离"排序。报价弹窗是一个BottomSheet组件，司机输入报价金额后提交POST /api/orders/:id/bids。

5.2 Node.js环境安装：从0到能跑起项目的完整路径

后端部分，环境搭建第一步是装Node.js。这里既有时间精力，也有一堆坑。先说结论：生产/开发环境装LTS版本，不要装Current版本。原因是LTS（Long Term Support）版本有较长的维护周期，生态工具链兼容性最好。

我的安装路径是：去Node.js官网下载LTS版本的安装包（Windows下是.msi文件，macOS下是.pkg），一路默认安装。安装完成后终端跳出这一行：

node -v

看到版本号（比如v20.11.1）就说明装好了。同时npm -v能看到npm版本号。如果是Linux服务器，有一票常见的安装方式：通过包管理器直接安装（大概率是旧版本），或者用nodesource仓库装指定版本，或者用nvm管理多版本。我个人推荐nvm，因为后续项目可能需要切换Node版本，nvm可以随时切换。

有一个容易踩的坑：下载了Node.js安装包但路径没有正确加入环境变量，导致终端里输入node提示"不是内部或外部命令"。Windows下的解决办法是在系统环境变量里把Node.js的安装目录（默认是C:\Program Files\nodejs\）加到Path变量里，然后重开一个新终端。macOS如果用了.pkg一般会自动配好，但如果你是从tar包手动解压的，同样需要手动配置环境变量。

我还遇到过一种报错：error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。这种报错是nvm切了一个不存在的版本号。解决思路很简单：先执行nvm ls-remote查看目前可用的Node.js版本列表（尤其是LTS版本号），再nvm install v20.11.1这样的具体版本，不要凭空填写一个不存在的版本号。

5.3 后端工程化落地：Express项目初始化到Socket.io接入

Node.js后端项目我用一个脚手架命令初始化的：

mkdir taxi-backend && cd taxi-backend npm init -y npm install express sequelize mysql2 socket.io jsonwebtoken bcryptjs dotenv npm install -D nodemon eslint prettier

项目目录结构如下：

taxi-backend/ ├── src/ │ ├── config/ # 配置文件（数据库连接、环境变量） │ ├── models/ # Sequelize 数据模型 │ ├── controllers/ # 业务逻辑控制器 │ ├── routes/ # 路由定义 │ ├── middlewares/ # 认证、错误处理中间件 │ ├── services/ # 核心业务服务层（订单状态机、计费） │ ├── sockets/ # Socket.io 事件处理 │ └── utils/ # 工具函数（密码加密、Token生成） ├── .env └── app.js

.env文件用来存环境变量，格式是键值对：

PORT=3000 DB_HOST=localhost DB_USER=root DB_PASSWORD=yourpassword DB_NAME=taxi_clone JWT_SECRET=your_secret_key

不要把这个文件提交到Git仓库，这类密钥一旦泄露就是安全事故。业内习惯是在.gitignore里加上.env，然后项目里保留.env.example作为模板，把字段名列出来但不填真实密钥，新成员拿到仓库后复制.env.example为.env再填自己的配置。

数据库初始化用Sequelize的sync方法可以快速建表（开发阶段够用），生产环境强烈建议用迁移脚本（migrations）管理表结构变更。我在项目里用的是sequelize-cli，每次改动表结构都生成一个迁移文件，保证任何环境能安全地升级数据库。第一次表结构同步还有一个小坑：如果表之间有关联外键，sync的顺序不能乱，要先建被关联的表，否则会报"Can't create table"的错误。

Socket.io和后端HTTP服务可以共用同一个端口。通过http.createServer(app)创建HTTP服务器，然后把Socket.io实例挂到这个服务器上：

const http = require('http'); const socketIO = require('socket.io'); const server = http.createServer(app); const io = socketIO(server, { cors: { origin: "*" } }); server.listen(process.env.PORT || 3000, () => { console.log(`Server is running on port ${process.env.PORT || 3000}`); });

这里有个生产环境一定要做的事：Socket.io的cors不要用"*"，要指定允许的来源域名或IP列表。不然任意网站都能连上你的socket服务，被拉去当肉鸡发垃圾消息都不知道。

6. 常见问题与排查技巧实录：从定位失效到订单状态错乱

6.1 Node.js安装和开发环境的5个高频坑

1. npm安装依赖时报node-gyp错误。这个大多是因为本地没有装C++编译工具链。Windows下执行npm install --global windows-build-tools，macOS下执行xcode-select --install安装Command Line Tools，问题基本就解决了。有个替代方案：Node.js生态里的node-gyp帮你在编译原生模块时找到编译工具链，如果你要装的模块是纯JavaScript，就不需要编译工具。

2. 端口被占用。启动后端时如果报EADDRINUSE，说明3000端口已经被某个进程占了。Windows下用netstat -ano | findstr :3000查到占用进程的PID，然后taskkill /PID <pid> /F干掉；macOS/Linux下用lsof -i:3000看占用情况，kill -9 <pid>处理。

3. MySQL数据库连接失败。通常是密码不对或者用户权限只有localhost没有远程权限。检查.env里的配置是一步，另一步确认MySQL服务确实在运行：sudo systemctl status mysql（Ubuntu环境）。数据库连接池建议在配置里加上pool: { max: 10, min: 0 }，避免连接数不够导致的时报错。

4. JWT Secret为空。如果.env没正确加载，JWT_SECRET字段就是空字符串，这样生成的token所有用户通用，失去鉴权意义。排查方法是启动时打印process.env.JWT_SECRET是否正常，同时确认dotenv在项目入口文件的第一行调用。

5. React Native调试时Metro缓存旧代码。改了前端代码，刷新页面还是旧效果，这个需要清理缓存：npx react-native start --reset-cache。如果是iOS的Pods缓存问题，删除ios/Pods目录重新pod install。

6.2 Android真机调试的3个必踩坑和解决套路

Android真机调试烦人的地方在于环境相关的问题极其隐蔽。

设备连上电脑后adb devices看不到设备，基本是USB调试没打开或者驱动没装好。这里有个实用技巧：手机上打开"开发者选项"里的"USB调试"，连接后手机上会弹"允许USB调试吗"，必须点允许，点拒绝的话后面一切操作都没意义。

Compass方式运行调试版本，App启动后一直卡在白色启动页，八成是Metro服务连接不上。开发者菜单里选"Settings"，把Debug server host改成电脑的局域网IP，比如192.168.1.100:8081。如果你改的时候不知道电脑IP，Windows下ipconfig、macOS/Linux下ifconfig或ip addr查。

Release包安卓版访问HTTP接口请求报错，这个不是Node后端的问题，是因为Android 9（API 28）开始默认禁止明文HTTP流量。如果你用的接口地址是http://而不是https://，需要在AndroidManifest.xml的<application>标签上加android:usesCleartextTraffic="true"。但上线前一定要换回HTTPS，明文传输在公网简直是在裸奔。

6.3 订单状态错乱：一次典型的并发问题排查实录

第二轮迭代测试时，测试同事报了一个问题：乘客和司机同时在订单进行中，乘客取消了订单，司机端还能正常点"完成行程"，最后产生了"已完成但已取消"的脏数据。

排查过程分三步。第一步，看订单状态流转日志，确认是不是接口被重复调用；第二步，看代码逻辑，发现取消接口和完成行程接口在service层各自独立做状态判断，但没锁住同一条订单记录；第三步，复现并发场景，用两个终端同时请求取消和完成接口，果然能稳定复现。

解决办法：在订单表加一个lock_version字段（乐观锁版本号），每次更新状态时把预期的版本号放在WHERE条件里：

const result = await Order.update( { status: 'cancelled', lock_version: order.lock_version + 1 }, { where: { id: order.id, status: 'pending', lock_version: order.lock_version } } ); if (result[0] === 0) { // 更新影响行数为0，说明并发条件下有人先改了这条订单 throw new ApiError('订单状态已变更，请刷新重试', 409); }

这套"乐观锁+预期条件"方案可以处理大量并发场景，实现成本又低。从那次之后，所有涉及订单状态变更的接口都统一走了这个逻辑。

我个人在实际操作中的体会是：开发这种多角色、多状态流转的业务系统，最大的风险从来不是某个单独功能做不出来，而是各种操作"叠着来"的时候系统还能不能保持一致。所以现在回头看，这个项目里最有价值的部分不是哪个页面做得多炫，而是从状态机设计到并发控制这一整套应对"真实混乱"的机制。

这个内容后续如果想继续扩展，我认为有三条清晰的方向：一是把支付换成真实微信/支付宝接入，补上支付回调处理这关键一环；二是加入消息推送服务（比如极光或个推），解决App不在前台时也能收到订单通知的问题；三是把供需热点分析做成一个简单后台看板，展示每个区域的实时订单密度和司机密度。这三块做完，这个克隆项目的完整度会比现在高一个量级。