简介：这份资源是面向微信小程序开发者与全栈学习者的共享单车项目实战代码包，包含小程序前端与后端服务两部分，可帮助读者理解摩拜类应用的完整实现流程。包内共474个文件，以gif动图、xml配置、png图片、js脚本、css样式、java源码、json数据及wxml/wxss页面文件为主，另有少量class、html、properties等，压缩包约2.66MB，结构覆盖界面设计、交互逻辑与后端接口。项目涉及小程序UI构建、RESTful API设计、地理定位、地图服务集成、支付系统对接及数据安全等知识点，后端提供用户、单车、区域等业务模块，便于对照学习接口调用与数据管理。目前已有557人学习下载，适合希望提升全栈能力、理解线上线下结合业务逻辑的开发者参考实践。
1. 从一份「小程序 + 后端代码」压缩包说起：共享单车项目到底能跑出什么
拿到「基于小程序的共享单车项目(小程序+后端代码) .zip」这种交付物，第一反应往往不是兴奋，而是犯嘀咕：解压出来到底能不能跑？小程序端和后端是不是对得上？数据库脚本全不全？我见过太多人把这类压缩包解压完，微信开发者工具一编译就报一堆错，后端一启动就卡在数据库连接上，最后项目在硬盘里吃灰。这个标题背后其实是一套完整的「扫码开锁—计费—关锁结算」闭环：小程序负责扫码、地图找车、行程展示，后端负责车辆状态、订单、计费规则和支付回调。它适合想练手全栈的开发者、想拿共享单车场景做课程设计的学生，也适合想快速搭一套物联网租赁原型的团队。这一章先把这套东西的边界讲清楚，后面几章再一层层拆开怎么落地。
共享单车这个场景看着简单，真正难的是「状态一致性」：一辆车在同一时刻只能被一个人骑走，扫码、开锁、计费、关锁这几步里任何一步网络抖动，都可能出现「车锁开了但订单没生成」或者「关锁了还在计费」的玄学问题。所以这份代码的价值不在于界面多好看，而在于它怎么用后端把车辆状态机管住。热搜里「共享单车之数据分析」「小程序抓包」「微信小程序登录获取手机号」这些词，其实都指向同一个诉求：大家想知道这套系统怎么鉴权、怎么防刷、数据怎么沉淀。接下来我会按「先跑通、再讲原理、最后避坑」的顺序，把小程序端、后端、数据库和联调这几块讲透，让你拿到压缩包后能真正跑起来，而不是停在解压那一步。
2. 小程序端怎么搭：从登录鉴权到扫码开锁的最小闭环
小程序端是整个项目的门面，也是用户唯一直接接触的部分。它的核心链路其实就四条：微信登录换 openid、获取手机号做实名、扫码识别车辆编号、发起开锁请求并轮询状态。很多人一上来就纠结 UI，结果登录都没打通，后面全是空中楼阁。我一般建议先把鉴权跑通，再往上叠业务，这样每一步都有可验证的结果。
2.1 微信登录与手机号获取：openid 和 session_key 怎么落地
微信小程序的登录不是传统账号密码，而是wx.login拿到临时 code，传给后端换 openid 和 session_key。热搜里「微信小程序登录获取手机号」之所以被反复搜，是因为手机号获取在 2021 年后改成了getPhoneNumber按钮触发、后端解密的方式，老教程里的wx.getUserInfo早就不能用了。下面是最小可用的登录代码。
// pages/login/login.js Page({ data: { openid: '' }, onLoad() { // 静默登录：拿 code 换 openid，用户无感知 wx.login({ success: (res) => { if (!res.code) return; wx.request({ url: 'https://your-domain.com/api/auth/login', method: 'POST', data: { code: res.code }, success: (r) => { // 后端返回自定义登录态 token，存本地 wx.setStorageSync('token', r.data.token); this.setData({ openid: r.data.openid }); } }); } }); }, // 用户点击按钮授权手机号 getPhone(e) { // e.detail.code 是新的手机号 code，需后端调接口解密 wx.request({ url: 'https://your-domain.com/api/auth/phone', method: 'POST', header: { Authorization: wx.getStorageSync('token') }, data: { code: e.detail.code }, success: (r) => { console.log('手机号绑定成功', r.data.phone); } }); } });这段代码的逻辑是：wx.login静默拿到 code，后端用 code + appid + secret 调微信接口换 openid，生成自己的 token 返回。手机号部分注意，getPhoneNumber返回的e.detail.code是新版方案，后端拿它去调phonenumber.getPhoneNumber接口解密，不再需要前端传 encryptedData 和 iv。参数上，appid和secret必须放后端，绝不能写在小程序里，否则被人抓包就泄露了。token 建议用 JWT，有效期设 2 小时，配合 refresh 机制。
提示：开发阶段可以在微信开发者工具里勾选「不校验合法域名」，但上线前必须把后端域名配到小程序后台的 request 合法域名里，否则真机一定请求失败。
2.2 扫码识别与开锁请求：车辆编号怎么传、状态怎么轮询
扫码用的是wx.scanCode，拿到的是车辆上的二维码内容，通常是一串车辆编号或者带签名的 URL。这里有个坑：二维码内容不能直接当车辆 ID 用，最好后端校验签名，防止有人伪造二维码。开锁请求发出后，车辆不会立刻响应，因为真实单车走的是蓝牙或 4G 模块，所以前端要轮询开锁结果。
// pages/scan/scan.js Page({ scanAndUnlock() { wx.scanCode({ onlyFromCamera: true, // 只允许相机扫码，防止从相册选图伪造 success: async (res) => { const bikeNo = res.result; // 二维码内容 const token = wx.getStorageSync('token'); // 发起开锁 const { data } = await wx.request({ url: 'https://your-domain.com/api/bike/unlock', method: 'POST', header: { Authorization: token }, data: { bikeNo } }); if (data.code !== 0) return wx.showToast({ title: data.msg, icon: 'none' }); // 轮询开锁状态，最多 10 次，每次间隔 1.5 秒 let tries = 0; const timer = setInterval(async () => { tries++; const r = await wx.request({ url: `https://your-domain.com/api/bike/status?orderId=${data.orderId}`, header: { Authorization: token } }); if (r.data.status === 'unlocked') { clearInterval(timer); wx.showToast({ title: '开锁成功' }); wx.navigateTo({ url: `/pages/riding/riding?orderId=${data.orderId}` }); } if (tries >= 10) { clearInterval(timer); wx.showToast({ title: '开锁超时', icon: 'none' }); } }, 1500); } }); } });逻辑说明：扫码后把 bikeNo 传给后端，后端做三件事——校验车辆是否存在、校验车辆是否可用、创建订单并把车辆状态置为「锁定中」。返回 orderId 后前端轮询状态。参数上，轮询间隔 1.5 秒、最多 10 次是我实测比较稳的组合，太频繁会给后端压力，太慢用户体验差。onlyFromCamera: true是防刷的关键，否则有人截图二维码就能远程开锁。
2.3 地图找车与车辆列表加载更多
地图找车用map组件加markers，车辆列表用scroll-view配合分页。热搜里「微信小程序页面列表加载更多」就是这个场景。核心是后端按经纬度范围查询附近车辆，前端做上拉加载。
// pages/map/map.js Page({ data: { markers: [], page: 1, hasMore: true }, onLoad() { this.loadNearby(); }, async loadNearby() { if (!this.data.hasMore) return; const { latitude, longitude } = await this.getLocation(); const res = await wx.request({ url: 'https://your-domain.com/api/bike/nearby', data: { lat: latitude, lng: longitude, page: this.data.page, size: 20 } }); const list = res.data.list; // 转成 map 组件的 markers 格式 const markers = list.map(b => ({ id: b.id, latitude: b.lat, longitude: b.lng, iconPath: '/images/bike.png', width: 32, height: 32 })); this.setData({ markers: [...this.data.markers, ...markers], page: this.data.page + 1, hasMore: list.length === 20 }); }, getLocation() { return new Promise((resolve) => { wx.getLocation({ type: 'gcj02', success: resolve }); }); } });这里type: 'gcj02'必须写，因为微信地图和腾讯地图用的是 gcj02 坐标系，用 wgs84 会偏移几百米。分页 size 设 20 是平衡流量和体验的常见值。后端查询附近车辆时，简单做法是用经纬度范围过滤，数据量大了再上 GeoHash 或 Redis GEO。
3. 后端怎么设计：车辆状态机、订单与计费规则
后端是这个项目真正的核心，小程序只是壳。共享单车的后端难点集中在三块：车辆状态怎么管、订单怎么和车辆状态联动、计费规则怎么算。热搜里「共享单车之数据分析」其实就依赖后端把订单和车辆轨迹沉淀好。这一章讲清楚状态机和订单表设计，再给计费规则的实现。
3.1 车辆状态机：一辆车在同一时刻只能被一个人骑
车辆状态一般有四种：空闲（idle）、锁定中（locking）、使用中（riding）、故障（fault）。状态流转必须是原子的，否则并发扫码会出现两个人同时开同一辆车。常见做法是用数据库的行锁或者 Redis 分布式锁。
# bike_service.py import redis from models import Bike, Order, db r = redis.Redis() def unlock(bike_no, user_id): bike = Bike.query.filter_by(bike_no=bike_no).first() if not bike: return {'code': 1, 'msg': '车辆不存在'} # 用 Redis 锁保证同一辆车同一时刻只有一个请求能改状态 lock_key = f'bike:lock:{bike.id}' if not r.set(lock_key, user_id, nx=True, ex=10): return {'code': 2, 'msg': '车辆正在被操作'} try: if bike.status != 'idle': return {'code': 3, 'msg': '车辆不可用'} bike.status = 'locking' order = Order(user_id=user_id, bike_id=bike.id, status='unlocking') db.session.add(order) db.session.commit() # 这里调用硬件开锁接口（真实项目走 MQTT 或 TCP） send_unlock_command(bike.device_id) return {'code': 0, 'orderId': order.id} finally: r.delete(lock_key)逻辑说明：r.set(nx=True, ex=10)是 Redis 的原子 setnx，保证只有一个请求能拿到锁，10 秒过期防止死锁。拿到锁后检查车辆状态，改状态、建订单、发开锁指令。参数上，锁过期时间 10 秒要大于硬件响应时间，一般硬件 3 到 5 秒能回。真实项目里开锁指令走 MQTT，硬件回执后再把订单状态改成 riding，这里为了简洁省略了。
3.2 订单表与计费规则：按分钟还是按次
订单表至少要存：用户、车辆、开始时间、结束时间、起终点经纬度、金额、状态。计费规则常见的是「起步价 + 时长费」，比如 1.5 元含 30 分钟，超出每分钟 0.1 元。
# billing.py from datetime import datetime def calc_fee(start_time, end_time): duration_min = (end_time - start_time).total_seconds() / 60 base_price = 1.5 # 起步价 base_minutes = 30 # 起步包含时长 per_min = 0.1 # 超出单价 if duration_min <= base_minutes: return base_price extra = duration_min - base_minutes return round(base_price + extra * per_min, 2)参数说明：起步价和单价建议做成配置表，不要硬编码，方便运营调价。round(..., 2)保留两位小数避免浮点误差。关锁时后端根据订单开始时间和当前时间算费用，再调支付。注意计费要以服务器时间为准，不能信客户端传的时间，否则有人改手机时间就能白骑。
3.3 关锁结算与支付回调
关锁流程是：硬件上报关锁事件 → 后端找到进行中的订单 → 算费用 → 生成支付单 → 用户支付 → 订单完成、车辆置空闲。支付回调必须做幂等，因为微信可能重复通知。
# order_service.py def close_lock(bike_id): bike = Bike.query.get(bike_id) order = Order.query.filter_by(bike_id=bike_id, status='riding').first() if not order: return order.end_time = datetime.now() order.amount = calc_fee(order.start_time, order.end_time) order.status = 'unpaid' bike.status = 'idle' # 关锁即释放车辆 db.session.commit() create_payment(order) def payment_callback(order_no, trade_no): order = Order.query.filter_by(order_no=order_no).first() # 幂等：已支付直接返回成功 if order.status == 'paid': return 'success' order.status = 'paid' order.trade_no = trade_no db.session.commit() return 'success'这里bike.status = 'idle'放在关锁时而不是支付后，是因为用户关锁后车就物理释放了，别人可以骑，费用是欠着的。支付回调的幂等判断是血泪经验，少了这一步会出现重复扣款或者订单状态错乱。
4. 数据库与联调：把小程序和后端接起来
代码能跑和能联调是两回事。这一章讲数据库表怎么建、接口怎么对齐、本地怎么模拟硬件，让你在没有真实单车的情况下也能把整条链路跑通。
4.1 核心表结构与索引
至少需要用户表、车辆表、订单表、计费配置表。车辆表的经纬度字段要建索引，否则附近查询会全表扫描。
CREATE TABLE bike ( id BIGINT PRIMARY KEY AUTO_INCREMENT, bike_no VARCHAR(32) UNIQUE NOT NULL, device_id VARCHAR(64), status VARCHAR(16) DEFAULT 'idle', lat DECIMAL(10,7), lng DECIMAL(10,7), INDEX idx_status (status), INDEX idx_location (lat, lng) ); CREATE TABLE `order` ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) UNIQUE NOT NULL, user_id BIGINT NOT NULL, bike_id BIGINT NOT NULL, start_time DATETIME, end_time DATETIME, amount DECIMAL(10,2) DEFAULT 0, status VARCHAR(16) DEFAULT 'unlocking', INDEX idx_user (user_id), INDEX idx_bike_status (bike_id, status) );idx_location用经纬度联合索引只能做范围过滤，数据量大时建议上 Redis GEO 或者 PostGIS。idx_bike_status是为了快速查某辆车进行中的订单，关锁时用得上。
4.2 本地模拟硬件：没有真车也能跑通开锁
真实项目里开锁指令发给硬件，本地开发没有硬件，可以写一个模拟器，收到指令后延迟 2 秒回调后端。
# mock_device.py import requests, time def send_unlock_command(device_id): # 模拟硬件：延迟 2 秒后回调后端上报开锁成功 time.sleep(2) requests.post('http://localhost:8000/api/device/report', json={ 'deviceId': device_id, 'event': 'unlocked' })把这个函数替换掉真实的下发逻辑，整条链路就能在本地跑通。参数上，延迟 2 秒是模拟硬件响应，真实硬件一般 3 到 5 秒。回调接口/api/device/report收到后把订单状态改成 riding。
4.3 接口对齐：小程序和后端的字段约定
联调最容易翻车的地方是字段名对不上。建议后端统一返回{code, msg, data}结构，code 为 0 表示成功。小程序端封装一个 request 方法统一处理 token 和错误。
// utils/request.js const BASE_URL = 'https://your-domain.com'; export function request(options) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data, header: { Authorization: wx.getStorageSync('token') }, success: (res) => { if (res.data.code === 0) resolve(res.data.data); else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: reject }); }); }这样所有接口都走统一入口，token 过期、错误提示都在一处处理，改起来方便。
5. 避坑与排查：这套代码最容易翻车的 5 个地方
这一章是我踩过的坑，按「现象 → 原因 → 解决」写，你遇到问题可以直接对号入座。
现象一：小程序真机请求全部失败，开发者工具却正常。原因：开发者工具默认不校验域名，真机必须走 HTTPS 且域名在小程序后台白名单里。解决：把后端域名配到「开发管理—开发设置—服务器域名」，且必须是备案过的 HTTPS 域名，本地调试用内网穿透工具临时映射。
现象二：两个人同时扫同一辆车，都提示开锁成功。原因：车辆状态检查没有加锁，两个请求同时读到 idle。解决：用 Redis setnx 加锁，或者数据库UPDATE bike SET status='locking' WHERE id=? AND status='idle'判断影响行数，为 0 就说明被别人抢了。
现象三：关锁后还在计费，或者计费金额为负。原因：关锁事件重复上报，或者订单开始时间用了客户端时间。解决：关锁接口做幂等，订单状态不是 riding 就直接返回；计费统一用服务器时间，开始时间以订单创建时服务器时间为准。
现象四：支付回调重复执行导致重复扣款。原因：微信支付回调可能多次通知，代码没做幂等。解决：回调入口先查订单状态，已 paid 直接返回 success，用数据库唯一约束兜底。
现象五：附近车辆查询越来越慢。原因：经纬度范围查询全表扫描，数据量上万后明显卡顿。解决：先加联合索引顶一阵，数据量再大就上 Redis GEO，把车辆位置存进去，用GEORADIUS查附近。
6. 进阶：把共享单车项目做成能写进简历的样子
跑通只是起点，真正让这个项目有价值的是你能不能在上面加东西。我一般会从三个方向做进阶：数据分析、防刷风控、性能优化。数据分析这块，热搜里「共享单车之数据分析」不是空话，你可以基于订单表做车辆周转率、高峰时段、热点区域的分析，用 Python 的 pandas 跑一遍，输出几张图表，这就是简历上能写的东西。
# analytics.py import pandas as pd df = pd.read_sql('SELECT * FROM `order` WHERE status="paid"', con=engine) df['start_time'] = pd.to_datetime(df['start_time']) df['hour'] = df['start_time'].dt.hour # 各时段订单量 hourly = df.groupby('hour').size() # 车辆周转率：每辆车每天被骑次数 turnover = df.groupby(['bike_id', df['start_time'].dt.date]).size().mean() print('高峰时段:', hourly.idxmax(), '点') print('平均每车每日周转:', round(turnover, 2), '次')这段代码能直接跑出高峰时段和周转率，参数上注意status="paid"只统计已完成订单，否则会把取消的也算进去。防刷风控可以在开锁接口加频率限制，同一用户 1 分钟内最多开锁 3 次，用 Redis 计数器实现。性能优化则是把附近查询换成 Redis GEO，我实测车辆数到 5 万时，GEO 查询比 SQL 范围查询快一个数量级。
验证方法上，我习惯用 Postman 或 Apifox 把每个接口单独跑一遍，确认参数和返回，再走小程序联调。压测可以用 locust 模拟 100 个用户同时扫码，看 Redis 锁和数据库扛不扛得住。最后说个我自己的习惯：每次改完计费规则，我都会手动造几笔边界订单——刚好 30 分钟、31 分钟、跨天——跑一遍算费，因为计费是最容易出线上事故的地方，宁可多测十分钟，也别等用户投诉。希望帮到你。
本文还有配套的精品资源，点击获取
