PHP+H5自建网约车打车平台：架构与实战避坑指南

简介一套基于Yii框架开发的PHP网约车H5打车系统源码分为乘客端、司机端与后台管理端三端共用同一个数据库适合需要快速搭建网约车平台、研究H5叫车流程或进行二次开发的PHP工程师。包体共2000个文件大小约139.82MB除常见JS脚本、HTML页面、CSS样式外还包含SQL数据库脚本、JSON配置、Markdown说明文档以及TXT、XML等辅助文件。其中SQL脚本用于初始化数据表JSON配置勾画业务参数Markdown文档帮助快速理解源码整体目录结构清晰便于按模块部署与调试。资源内提供后台/admin入口及默认账号并给出打车后台、前台、司机端三个演示地址按照说明修改数据库配置即可跑通完整业务流程。已有629人学习下载对想掌握Yii框架多端开发、网约车业务逻辑、前后台数据交互的开发者是一份可直接用于实战的完整源码。1. 一个区域车队要自建打车平台为什么选了PHP和H5这套组合你拿到的这套 PHP网约车H5打车系统源码——乘客端与司机端完整解决方案核心不是把App换成网页那么简单而是把“乘客下单、司机接单、行程计费、支付结算”这整条闭环用一套PHP后端和两个H5前端扛下来。适合两类人手里有运力、想快速自建品牌的车队给中小出行公司做交付的开发者。先说结论H5的优势不是技术是触达成本乘客扫二维码就能叫车司机登录浏览器就能听单。PHP的定位是把订单状态管住把长连接、地图、支付这些重活交给更合适的组件。下面从架构边界开始拆。2. 从架构看这套PHP网约车系统的边界哪些PHP做哪些必须交给扩展2.1 为什么PHP能撑住业务核心是状态而不是高并发长连接很多人一听网约车就觉得要上Java/Go理由是司机端要保持长连接、要低延迟抢单。这个判断对了一半。网约车真正的高频动作是订单状态流转创建订单、司机接单、行程开始、行程结束、支付完成。这些操作都是短请求天然适合PHP擅长的“请求-响应”模型。真正需要长连接的只有两个地方司机端听单推送、乘客端行程状态实时更新。常见做法是把这两条长连接通道独立出去用Workerman或Swoole做常驻内存网关PHP业务接口负责生成订单、改状态、算费用两者之间通过Redis Pub/Sub通信。PHP只做它擅长的事校验参数、读写MySQL、写业务日志、返回统一JSON结构。这么拆之后PHP单机撑几千日单量很轻松瓶颈通常在数据库和地图接口限流不在PHP本身。提示别让PHP进程直接维护WebSocket连接池PHP-FPM生命周期太短连接状态无处存放。长连接必须交给常驻进程这是这套方案能不能上线的前提。2.2 订单状态机与数据表设计乘客端与司机端共享同一套订单数据先说状态机。网约车订单最忌讳把状态散落在各个字段里比如用 is_cancel、is_start、is_finish 这种并列字段拼状态后期改一个需求就要动三张表。正确做法是单一status字段加状态机约束这套系统的订单状态建议这样定状态码含义触发方允许的下一个状态10待接单乘客创建订单20 / 6020司机已接单待乘客上车司机抢单成功30 / 6030行程中司机点击开始计费40 / 6040待支付司机点击结束计费50 / 6050已完成乘客支付成功/免密扣款成功无60已取消乘客或司机取消无所有状态流转写在一个PHP常量类里接口层禁止直接拼字符串。下面给出订单主表和轨迹点表的核心DDL这是乘客端和司机端共用的同一套数据差别只是查询条件里的角色不同。CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号前端展示用, passenger_id INT UNSIGNED NOT NULL COMMENT 乘客用户ID, driver_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 接单司机ID0表示未接, status TINYINT UNSIGNED NOT NULL DEFAULT 10 COMMENT 状态机见状态码表, start_lng DECIMAL(10,6) NOT NULL COMMENT 起点经度GCJ02, start_lat DECIMAL(10,6) NOT NULL, start_address VARCHAR(255) NOT NULL, end_lng DECIMAL(10,6) NOT NULL, end_lat DECIMAL(10,6) NOT NULL, end_address VARCHAR(255) NOT NULL, estimate_fee DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 预估费用, real_fee DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 实际费用, distance_meters INT UNSIGNED NOT NULL DEFAULT 0, created_at DATETIME NOT NULL, accepted_at DATETIME DEFAULT NULL, started_at DATETIME DEFAULT NULL, finished_at DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status_created (status, created_at), KEY idx_driver_status (driver_id, status), KEY idx_passenger_created (passenger_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_track_points ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, lng DECIMAL(10,6) NOT NULL, lat DECIMAL(10,6) NOT NULL, speed DECIMAL(5,2) NOT NULL DEFAULT 0 COMMENT 瞬时速度km/h, created_at DATETIME NOT NULL, PRIMARY KEY (id), KEY idx_order_time (order_no, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单号不要用自增ID暴露给前端用日期随机数生成32位字符串避免乘客通过订单号遍历他人订单。索引设计上待接单列表按 status created_at 查司机端“我的订单”按 driver_id status 查这两个索引能覆盖大部分查询。轨迹点表单独拆出来是因为行程结束后要做里程计算和投诉取证原始轨迹点必须全量保留不能为了省存储只留抽稀后的点。抽稀只影响展示不影响计费凭证。2.3 地图、支付、短信这些外部能力接口选型与密钥管理这套系统的外部依赖有四个地图定位、支付、短信、OCR证件识别。选型建议是地图定位和逆地理编码用同一家服务商高德或腾讯都行乘客端H5的JS SDK、司机端H5的JS SDK、后端逆地理编码接口必须全部指向同一家否则坐标系会乱。支付走微信支付和支付宝其中免密支付要和支付服务商单独签约这不是普通支付接口能搞定的。密钥管理有一条铁律地图Key、支付商户号、短信签名全部放PHP服务端环境变量前端JS只拿一个受限的Key。H5页面里的JS是会被人扒下来看的服务端Key一旦出现在页面源码里马上就会被人拿去刷接口。常见做法是后端配置两个Key一个浏览器端Key只开Web端JS API和指定域名白名单一个服务端Key只允许服务端IP调用。跨域问题也会在这一层暴露。乘客端H5、司机端H5、管理后台可能是三个域名PHP API单独一个域名接口要开启CORS早期项目里常见的jsonp方案只适合GET请求下单、支付这类写操作不要用jsonp。3. 乘客端H5落地定位、下单、状态跟踪的完整链路3.1 乘客端定位与坐标纠偏前端定位不是拿到坐标就能用乘客端H5打开就是地图选点。定位逻辑分三步先尝试HTML5的navigator.geolocation失败或精度不够再降级到地图JS SDK的定位接口最后让用户手动选点。这里有一个必须做的校验定位接口返回的accuracy大于100米时不能直接把坐标带入下单接口要提示用户“定位精度不足请手动选择上车点”并展示地图让用户确认。function locatePassenger() { return new Promise((resolve, reject) { if (!navigator.geolocation) { reject(new Error(geolocation unsupported)); return; } navigator.geolocation.getCurrentPosition((pos) { const coords { lng: pos.coords.longitude, lat: pos.coords.latitude, accuracy: pos.coords.accuracy }; if (coords.accuracy 100) { reject(new Error(low accuracy: coords.accuracy)); return; } resolve(coords); }, (err) { reject(err); }, { enableHighAccuracy: true, timeout: 10000, maximumAge: 5000 }); }); }enableHighAccuracy 必须开不然手机上拿到的可能是基站定位误差几百米。timeout给10秒超过就降级。拿到坐标后先调后端逆地理编码接口把经纬度换成地址描述展示给乘客确认不要直接拿前端填写的地址下单前端地址可以随便用input拼出来不可信。另一个移动端H5的体验坑是地址输入框的键盘遮挡。乘客点击起点输入框时键盘弹出会盖住下方的确认按钮安卓WebView尤其明显。处理办法是在input的focus事件里做一次scrollIntoView让输入框滚到可视区域中间。3.2 下单接口与30分钟无人接自动取消Redis延迟队列兜底乘客确认起点终点后前端把两个点的经纬度和地址POST到 /api/order/create。服务端要做四件事校验两个坐标距离是否过近小于50米直接拒绝避免下单后司机到了找不到人、查乘客是否有未完成订单一人只能有一单在途、重新计算预估费用、入库并推送司机端。public function create(Request $request) { $passengerId $request-input(passenger_id); $startLng $request-input(start_lng); $startLat $request-input(start_lat); $endLng $request-input(end_lng); $endLat $request-input(end_lat); // 判断起终点距离小于50米拒绝 $distance $this-calcDistance($startLat, $startLng, $endLat, $endLng); if ($distance 50) { return $this-error(起终点距离过近请重新选择); } // 一人只能有一单进行中 $exist Order::where(passenger_id, $passengerId) -whereIn(status, [10, 20, 30]) -exists(); if ($exist) { return $this-error(您有未完成的订单); } DB::beginTransaction(); try { $order Order::create([ order_no $this-genOrderNo(), passenger_id $passengerId, status 10, start_lng $startLng, start_lat $startLat, end_lng $endLng, end_lat $endLat, estimate_fee $this-calcEstimateFee($distance), ]); // 写入Redis延迟队列30分钟后无人接单自动取消 Redis::zadd(delay_cancel_order, time() 1800, $order-order_no); DB::commit(); return $this-success([order_no $order-order_no]); } catch (\Throwable $e) { DB::rollBack(); return $this-error(下单失败请重试); } }延迟队列用Redis的ZSET实现score存取消时间戳member存订单号。后台放一个常驻PHP脚本每秒取一次score小于当前时间的订单判断状态仍为10就执行取消。这套方案比定时任务扫全表高效得多而且脚本挂了可以重启续跑不会重复取消已进入行程的订单。3.3 订单详情页的状态同步轮询为主、推送为辅乘客端H5下单成功后跳转到订单详情页页面需要实时展示待接单状态、司机接单后的车辆位置、行程中的轨迹。这里我一般用轮询做主链路WebSocket做增强。原因很简单乘客端页面是碎片化使用的用户下单后可能切到微信聊天再切回来一个长连接在页面切走时就会被系统杀掉维护成本高效果也不比轮询好。轮询接口返回订单状态、司机经纬度、司机手机号脱敏、预计等待时间。间隔按状态调整待接单5秒一次司机已接单但还没上车时8秒一次行程中3秒一次。行程中司机位置变化快3秒能得到流畅的追车效果再快就没有意义了因为司机端GPS上报本身也是2到3秒一次。function pollOrderStatus(orderNo) { let timer null; let interval 5000; async function tick() { try { const res await fetch(/api/order/status?order_no orderNo); const data await res.json(); updateOrderUI(data.order); if (data.order.status 30) { interval 3000; } else if (data.order.status 20) { interval 8000; } else if (data.order.status 50) { clearInterval(timer); } clearInterval(timer); timer setInterval(tick, interval); } catch (e) { // 网络抖动时保持当前轮询频率不打断 } } tick(); }注意轮询失败时不要指数退避直接保持当前频率乘客端偶尔一次失败用户无感退避反而会让页面状态长时间不更新。如果接了推送网关可以在收到“司机已接单”“行程已结束”这类关键事件时立刻拉一次最新状态轮询照常兜底。3.4 费用预估与行程分享两个提升下单率的小功能费用预估直接复用计费规则后端算完随订单详情返回。为了减少投诉页面上必须写明“预估费用仅供参考实际金额以行程结束时的计费为准”。用一张城市计费规则表存起步价、里程单价、时长单价和夜间附加费接口层按城市编码查表乘客端不传计价参数防止有人篡改车费。行程分享是把H5订单页做成微信卡片利用微信JS-SDK的updateAppMessageShareData把标题写成“京A12345正在来接您”描述带上实时位置和预计到达时间。这个功能看似不起眼对车队拉新很有用乘客把行程分享到家人群里等于一次免费品牌曝光。卡片里的链接要带order_no参数对方打开只能看到行程跟踪页不能看到价格和乘客手机号。4. 司机端H5落地认证、抢单、计费这3件事必须可靠4.1 司机注册与资质上传文件校验、OCR识别与blob上传司机端H5的第一个页面是注册认证要传身份证正反面、驾驶证、行驶证还要做人车合照。这里最常被问到的一个问题是“h5 blob文件能上传吗”或者反过来“文件不能传怎么办”实际都可以传。前端用input拿到File对象后直接append进FormData交给fetch后端按multipart接收。如果文件较大可以做前端压缩把图片画到canvas里降采样后再转blob上传单张控制在2MB以内。function uploadDriverLicense(file) { const formData new FormData(); formData.append(file, file); formData.append(type, driver_license); return fetch(/api/driver/cert/upload, { method: POST, body: formData }).then(res res.json()); }后端校验不能只看扩展名。常见做法是三重判断扩展名、MIME类型、getimagesize读出的真实格式。扩展名是jpg但内容是个php文件的情况getimagesize会直接返回false这种文件在入库前就会被拦下。存储时不要用原始文件名重命名为随机字符串加白名单扩展名文件放到Web根目录之外或用OSS私有读写避免被人直接拼接URL下载。证件识别建议接云服务商的车牌/证件OCR接口把识别出的姓名、身份证号回填到表单司机少打一遍字注册转化率能明显提高。OCR后端调用时要注意身份证号里的数字不要做脱敏入库审核后台需要看到完整号码但接口返回给前端时要脱敏只显示前三位和后两位。4.2 附近订单推送与抢单并发Redis集合过滤数据库条件更新司机端登录后进入工作台前端通过WebSocket网关保持在线。这块常驻进程会定期把司机的位置写入Redis用有序集合按城市维度管理key是 city:online_driversmember是driver_idscore是距离乘客起点的距离只有距离3公里内的司机才会被拉入候选集合。新订单创建时PHP接口往Redis的频道 order.event 发一条消息长连接网关收到后取出该城市在线司机集合筛选出3公里内的司机ID逐个推送“您有新的订单”。抢单是整个系统并发压力最大的一环也是最容易翻车的一环。核心原则是不能先SELECT判断再UPDATE必须用一条带状态条件的UPDATE来保证只有一个司机抢成功。public function grab(Request $request) { $driverId $request-input(driver_id); $orderNo $request-input(order_no); $affected Order::where(order_no, $orderNo) -where(status, 10) -where(driver_id, 0) -update([ driver_id $driverId, status 20, accepted_at now() ]); if ($affected ! 1) { return $this-error(手慢了订单已被抢走); } // 发布事件通知乘客端司机已接单 Redis::publish(order.event, json_encode([ order_no $orderNo, event accepted, driver_id $driverId ])); return $this-success([grabbed true]); }affected是影响行数只有1才代表当前司机抢到。两个司机同时执行这条UPDATE时InnoDB的行锁会让第二个司机等第一个提交后再执行此时订单状态已经变成20第二个司机受影响行数为0。这里关键点在where条件里必须带上driver_id0只判断status还不够因为可能已经被同一个人重复提交。抢单成功后还要做两件事把司机ID写入Redis的忙碌司机集合避免同一个司机同时听两个单给司机端推送接单成功的语音播报指令这块由前端根据消息触发TTS后端不负责播报。另外抢单要有日志表记录每次抢单的司机ID、时间、订单号、成功与否运营上出现纠纷时这是定位问题的唯一凭证。4.3 行程计费与免密支付轨迹距离计算要保守司机点击开始计费后司机端H5开始批量上报GPS轨迹点后端按订单号追加写入order_track_points。结束计费时读出全部轨迹点用Haversine公式累加相邻两点距离再乘一个计费里程系数。系数默认0.95意思是对GPS估算里程打折宁可少收一点也不能因为多收引发投诉。function haversineDistance($lat1, $lng1, $lat2, $lng2) { $earthRadius 6371000; $dLat deg2rad($lat2 - $lat1); $dLng deg2rad($lng2 - $lng1); $a sin($dLat / 2) * sin($dLat / 2) cos(deg2rad($lat1)) * cos(deg2rad($lat2)) * sin($dLng / 2) * sin($dLng / 2); $c 2 * atan2(sqrt($a), sqrt(1 - $a)); return $earthRadius * $c; }计费规则建议按“起步价 超出起步里程的里程费 时长费 夜间附加费”拆成四段每段单独计算再累加不要直接算总价。因为夜间附加费是按“行程结束时间是否在22点到次日6点之间”判断的如果司机在21:55开始行程23:00结束那么只有22点之后的时段才算夜间混在一起算必投诉。免密支付签约后行程结束由服务端发起扣款。扣款失败不要改状态为已完成要把状态回退到40待支付并给乘客端推送一条带支付链接的消息。这里有一个边界乘客余额不足时支付回调可能延迟几分钟才返回订单状态不能卡在扣款中需要有一个补偿任务每5分钟扫一次状态为45“扣款中”的订单超过10分钟还没收到回调就主动查单。5. 常见问题与避坑上线前后最容易翻车的5个环节5.1 两个司机同时抢到一单并发下的幂等与防重现象刚上线时收到运营反馈两个司机手机上都提示“抢单成功”乘客端却只显示一个司机。原因第一版抢单接口用的是SELECT确认状态为空闲再UPDATE两个司机都查到了相同状态两个UPDATE都执行成功后一个把前一个覆盖了。解决所有抢单操作改成单条条件UPDATE用受影响行数判断是否成功不加SELECT预检查。同时Redis里用SETNX抢一个预占锁抢到锁才允许执行后续的订单变更。这样即使数据库因为主从延迟没及时同步Redis锁也能挡掉一部分重复请求。5.2 坐标对不上WGS84与GCJ02的强制转换现象乘客在楼内定位下单成功后司机到达的地点和乘客实际位置差了100多米经常隔一条街。原因前端H5的navigator.geolocation在某些Android机上返回的是WGS84原始坐标而高德/腾讯地图期望的是GCJ02加密坐标。两者不做转换地图上显示的点和GPS真实位置就会偏移。微信内置浏览器的getLocation在不同机型上返回的坐标系也不一致。解决后端统一收口坐标转换所有定位接口返回前强制转成GCJ02下面这个转换函数可以直接封装成公共方法。function wgs84ToGcj02($lng, $lat) { $a 6378245.0; $ee 0.00669342162296594323; $dLat transformLat($lng - 105.0, $lat - 35.0); $dLng transformLng($lng - 105.0, $lat - 35.0); $radLat $lat / 180.0 * M_PI; $magic sin($radLat); $magic 1 - $ee * $magic * $magic; $sqrtMagic sqrt($magic); $dLat ($dLat * 180.0) / (($a * (1 - $ee)) / ($magic * $sqrtMagic) * M_PI); $dLng ($dLng * 180.0) / ($a / $sqrtMagic * cos($radLat) * M_PI); return [ lng $lng $dLng, lat $lat $dLat ]; }定位、逆地理编码、路径规划、距离计算全部使用转换后的GCJ02全链路统一不要在地图SDK里再开“原始坐标”之类的选项。5.3 WebSocket频繁断线心跳、重连与状态补偿现象司机跑到商场地下车库或电梯里再出来时听单页面显示在线但收不到新订单推送有时切换Wi-Fi和4G后接单按钮一直转圈。原因移动网络变化会导致WebSocket连接静默断开服务端没有及时感知前端也没有在断线后主动补偿拉取状态。很多方案只做了心跳没做断线重连后的业务状态同步。解决三件事一起做。第一Nginx代理WebSocket时加上正确的升级头并调大超时时间第二前端30秒发一次业务心跳超过90秒没收到回应主动重连第三重连成功后调用一次订单状态同步接口把司机当前正在进行的订单、听单开关状态拉回来。location /ws { proxy_pass http://127.0.0.1:2345; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 300s; }心跳里同时带上司机当前经纬度等于把听单位置更新也捎带做了少一次额外请求。重连后的状态补偿非常关键不做的话司机端会一直显示在线但实际已经掉出听单队列。5.4 iOS上H5下载对账单变成预览响应头处理现象司机在iPhone的Safari里点“下载行程对账单”页面直接打开了文本内容无法保存到文件。安卓手机下载正常。原因iOS Safari对Content-Type为text/plain或application/json的响应体默认走预览不会触发下载部分H5里用window.open打开一个接口地址iOS会直接把返回内容当页面渲染。解决下载接口强制设置Content-Type为application/octet-stream并加上Content-Disposition附件声明让Safari识别为下载行为。public function downloadBill($orderNo) { $bill Order::where(order_no, $orderNo)-first(); $content $this-buildBillText($bill); $filename bill_ . $orderNo . .txt; return response($content) -header(Content-Type, application/octet-stream) -header(Content-Disposition, attachment; filename . $filename . ); }如果司机端是WebView内嵌的还需要在前端用a标签加download属性来配合不能只靠后端响应头。这条血泪经验是凡是给司机端的文件下载iOS和安卓要分开自测不要拿安卓的测试结果当结论。5.5 计费里程虚高被投诉GPS漂移过滤与凭证留存现象乘客投诉司机绕路后台拉出轨迹回放发现司机确实没绕路但订单里的计费里程比地图路径多了1.5公里。原因GPS在城市高架桥下、隧道里会漂移轨点乱跳到隔壁道路上累加距离时这些漂移点全部算进去了。这条坑非常隐蔽乘客看轨迹回放用的是地图厂商的路径匹配而计费用的是原始坐标点累加两边自然不一样。解决计费前做两层清洗。第一层剔除明显异常点速度超过120km/h对应的相邻点距离直接丢弃第二层做抽稀3秒内的中间点如果和前后两点连成的夹角小于某个阈值就丢掉只保留方向变化明显的关键点。算出来的距离要保留明细到订单扩展表投诉时可以精确到“第几个点到第几个点之间产生了多少米误差”。6. 用并发压测和订单审计脚本把两端数据对齐验证与进阶这套系统上线前我建议你亲手跑一遍并发抢单压测不要只在后台点几个按钮就收工。下面这个PHP脚本可以模拟100个司机同时抢同一单断言成功数量恰好等于1。$url http://api.example.com/api/order/grab; $orderNo 202501010000001; $mh curl_multi_init(); $handles []; for ($i 1; $i 100; $i) { $ch curl_init($url); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query([ driver_id $i, order_no $orderNo ])); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_multi_add_handle($mh, $ch); $handles[] $ch; } $running null; do { curl_multi_exec($mh, $running); curl_multi_select($mh); } while ($running 0); $successCount 0; foreach ($handles as $ch) { $body curl_multi_getcontent($ch); if (strpos($body, grabbed:true) ! false) { $successCount; } curl_multi_remove_handle($mh, $ch); } curl_multi_close($mh); echo success count: $successCount . PHP_EOL;跑完这一步再跑订单状态审计SQL把异常数据捞出来我习惯每周跑一次-- 无人接单超时未取消 SELECT order_no, status, created_at FROM orders WHERE status 10 AND created_at NOW() - INTERVAL 40 MINUTE; -- 行程中超过3小时未结束 SELECT order_no, driver_id, started_at FROM orders WHERE status 30 AND started_at NOW() - INTERVAL 3 HOUR; -- 已接单但司机和乘客端状态不一致司机端已开始行程订单还是待上车 SELECT order_no FROM orders WHERE status 20 AND accepted_at NOW() - INTERVAL 30 MINUTE;这两条验证路径加起来不到20分钟能挡住上线后80%的订单状态类故障。我个人的习惯是每次改动订单状态机或者抢单逻辑先跑并发脚本再跑审计SQL确认无误才上灰度。这套流程救过我很多次希望帮到你。本文还有配套的精品资源点击获取