简介：微信小程序凭借轻量、免安装的优势成为共享经济类项目的热门载体，而云开发模式则通过云函数与云数据库简化了后端搭建，让开发者能聚焦业务逻辑。地图定位、订单状态机及数据库设计等核心技术，共同支撑起从资源发布、智能匹配到交易结算的完整业务闭环。在校园毕设或实际工程中，停车位共享平台正是这类技术落地的典型场景，围绕其技术选型、系统架构与关键实现，梳理实践中的踩坑经验，能为同类小程序开发提供直接参考。 又是一年毕设季，后台私信里十个有八个都在问小程序相关的题目。我去年做的就是“基于微信小程序的停车位共享平台”，这个题目听起来常规，但实际做下来，从技术选型、业务设计到论文撰写，坑比想象中多得多。这篇就把我整个项目的复盘写出来，从为什么选这个题、技术栈怎么定，到地图组件、订单状态机、云开发数据库设计，再到论文结构、答辩准备，一条线捋清楚。如果你也在做类似的小程序毕设，或者单纯想做一个能跑通完整闭环的小程序项目，这篇应该能帮你省掉不少试错时间。
1. 项目选题与技术选型：为什么是停车位共享+微信小程序
1.1 选题背景与核心需求拆解
先说选题。停车位共享这个方向，本质上和共享单车、共享充电宝是同一个逻辑：一边是大量私家车位在特定时段（比如白天上班、晚上外出）空置，一边是开车的人到处找不到车位。这个矛盾在老旧小区、商圈周边尤其明显。当时选这个题，一是场景够真实，不用刻意编造需求；二是业务闭环完整，从信息发布、搜索匹配到交易结算，能体现一个完整软件项目的所有关键环节；三是微信小程序作为载体足够轻，用户扫一扫就能用，不用下载App，传播门槛低，这在答辩时是很好讲的一个点。
把这个题目拆开看，核心需求其实就三条：
- 车位主（资源方）能发布空闲车位，设置时段、价格、位置，管理订单。
- 车主（需求方）能按位置/价格/时段搜索车位，预订、导航、支付。
- 平台方需要一套订单流转、结算、信用管理的机制，保证交易双方可信、平台可运营。
对应到系统设计，就是三端：用户端小程序（搜车位、订车位、付钱）、车位主端（发布、上下架、收款）、管理后台（审核、统计、处理纠纷）。而这三端共享同一套业务数据和规则，这个规则在实际开发里就是订单状态机和计费引擎，后面会详细讲。
1.2 技术栈选型：原生小程序+云开发，还是自建后端？
这是毕设里最纠结的一个选择。技术栈直接决定你后面几个月的开发节奏，也影响论文里“系统设计”这一章怎么写。我当时对比了三条路：原生微信小程序 + 自建后端（Spring Boot）、原生微信小程序 + 微信云开发、uniapp + 自建后端。
先说结论：我选了原生小程序 + 微信云开发。原因很实际：
- 毕设时间有限，一个人要同时搞定前端、后端、数据库、论文、答辩PPT，自建后端意味着要写接口文档、做鉴权、部署服务器、处理跨域，工作量大且容易分心。
- 云开发提供了云数据库、云函数、云存储、云调用，用户登录用 openid 自动识别，不需要自己设计 token 体系，文件上传（比如车位照片）直接调云存储接口，这些能力正好覆盖了停车位业务的核心需求。
- 没有服务器部署和运维成本，演示的时候打开就能跑，不会因为环境问题翻车。
那有没有必要用 uniapp？如果你未来想把项目发到支付宝小程序、抖音小程序，uniapp 是合理的，但纯粹为了毕设，我建议谨慎。我见过不少同学用 uniapp 开发，结果在微信开发者工具里白屏，或者 H5 没问题、小程序一跑就挂，这种问题定位起来非常折腾。尤其 uniapp 的标签渲染和原生组件（比如 map、camera）的兼容性，在小程序端有各种奇奇怪怪的表现，调试成本不低。毕设讲究“稳”，尽量不引入不必要的跨端复杂度。论文里可以提一句“后续可扩展为 uni-app 实现多端发布”，这句话能体现你的思考，但实现上不必真的去踩那个坑。
云开发有个容易忽略的坑：云函数和数据库的权限配置。云开发数据库默认权限是“仅创建者可读写”，如果你把车位的集合权限设置不对，别人就查不到你发布的车位。我当时是统一走云函数读写数据库，数据库本身权限收紧，这样业务规则可以集中管理，也不会出现权限漏洞。代价是云函数写得多一点，但云函数里操作数据库对比直接用前端 SDK 操作，其实代码量差别不大，而且更安全。
2. 系统设计与核心模块拆解
2.1 用户角色与业务流程
这个系统的角色比普通的信息展示小程序要复杂，因为存在“车主”和“车位主”两个身份，而且一个人在小程序里可以同时是车主和车位主。这也是项目设计上第一个要讲清楚的地方。
我的方案是：用户表里用 role 字段区分身份，但允许一个人同时拥有两种身份。简单说，用户默认是车主，可以搜车位、订车位；如果他想把自己的车位分享出去，需要额外申请“车位主”身份，填写车位信息，提交审核。这样设计的原因很直接——如果你强制用户二选一，那一个既想出租自己车位、又想租别人车位的用户，就得切换账号，体验很差，业务上也不合理。
核心业务流程我用三句大白话总结：
- 车主订车位：搜附近车位 -> 看车位详情 -> 预约 -> 到停车场 -> 点击开始停车 -> 离场点击结束 -> 自动结算 -> 支付 -> 评价。
- 车位主发布车位：申请车位主 -> 填写车位位置（地图选点）-> 设置时段价格 -> 提交审核 -> 上架 -> 接收订单通知 -> 收入到账。
- 管理员审核：审核车位主资质 -> 审核车位信息 -> 处理用户投诉 -> 查看平台数据报表。
这里有一个我一开始没想清楚、后来被答辩老师追问的设计：预约和停车的区别。用户到了停车场，是直接确认“开始停车”还是“确认预约”？如果只是预约，车位会不会被一直占着？这个问题的本质是“车位的资源占用状态”怎么管理。我最终的设计是：车位有“空闲、已预约、使用中、休整（维护中）”四种状态。用户预约后，车位从空闲变成已预约，但会设置一个20分钟的保留期，超过保留期未到达则自动释放并计入一次违约；用户点击“开始停车”后，状态变成使用中，计费从此刻开始；点击“结束停车”后，状态恢复为空闲。这样既保证了车位主的车位不会被无限占用，也给用户留了缓冲时间。
2.2 数据库设计与核心表结构
云开发用的是文档型数据库，没有表关联和复杂查询，所以设计上要有意识地“冗余一些字段，减少查询次数”。我的数据集合一共六个：users、parking_spots、parking_orders、wallet_transactions、coupons、feedback。
users 集合关键字段：openid（自动生成）、nick_name、phone、avatar_url、role（user / owner / both）、credit_score、wallet_balance、created_at。
parking_spots 集合关键字段：
| 字段 | 说明 |
|---|---|
| spot_no | 车位编号 |
| owner_openid | 车位主身份标识 |
| address | 文字地址 |
| location | GeoJSON 格式的地理坐标（云开发支持 GeoPoint） |
| price_per_hour | 白天单价（元/小时） |
| price_night | 夜间包时段价格 |
| spot_type | 地上/地下 |
| status | 空闲/已预约/使用中/维护 |
| images | 车位照片 fileID 列表 |
| rating | 综合评分 |
| audit_status | 审核状态 |
parking_orders 集合核心字段：order_no、spot_id、user_openid、owner_openid、status、start_time、end_time、reserve_time、amount、payment_status、cancel_reason、refund_status。这里 order 里面同时存 user_openid 和 owner_openid，是刻意冗余，后面查车主订单和个人历史时不需要 join，一次查询就能拿到。
云开发数据库有个很值得利用的能力：地理位置查询。我在 parking_spots 里存了 GeoPoint 类型的坐标，查询附近车位时可以用db.command.geoNear({ geometry: db.Geo.Point(longitude, latitude), maxDistance: 5000 })，直接按距离排序列出5公里内的车位，不需要自己算两两距离，性能也很稳。这个功能在论文的“系统实现”里是个很好的亮点，能体现你不仅会调接口，还考虑了数据结构的合理性。
2.3 订单状态机与计费规则设计
订单状态是整个系统最核心的部分，没有之一。我用一个状态枚举来管理：
- 0 待支付（用户提交订单后，支付前）
- 1 未开始（已支付，可取消）
- 2 使用中（开始停车）
- 3 已完成（已结算）
- 4 已取消（用户取消/超时未支付）
- 5 已退款
流程是：用户选车位 -> 提交预约单（状态0）-> 支付押金或预付（状态1）-> 到点开始（状态2）-> 结束结算（状态3）。这里有一个细节：预约时要不要先付费？我最终采用“预约免费+停车后支付”的模式，预约时只锁定车位不扣费，用户到现场点了“开始停车”，系统才根据实际停车时长结算。这样做对用户更友好，但代价是会出现“预约了不来”的放鸽子行为，所以加了信用分机制：超时未到释放车位，信用分减10分，信用分低于60分不能再预约。
计费规则也别只做“每小时X元”这种简单逻辑，毕设要有亮点。我设计了分时段计费：工作日白天（8:00-20:00）按小时计费，夜间和非工作日有优惠，单日封顶，长租（包月）单独一口价。举个例子，一个车位日间每小时4元，夜间固定10元一晚，单日封顶25元。用户18:00到达、第二天9:00离开，费用就是：夜间包时段10元 + 次日早晨1小时4元，共14元，封顶规则兜底。这个计算放在云函数里，前端只展示计算结果，避免用户改设备时间作弊。这块逻辑是论文里“业务规则设计”的重要篇幅，也值得写进答辩PPT。
3. 关键技术实现与踩坑实录
3.1 地图选点与停车位距离计算
停车位共享平台绕不开地图。微信小程序里有 map 组件，这是官方封装好的地图容器，可以展示标记点、定位用户位置、画路线。但 map 组件本身只是一个展示层，要做“搜索附近车位”、“发布车位时选点”、“导航到车位”这些能力，还需要配合地图服务商的SDK。
有同学问“微信小程序可以使用天地图画地图组件吗”，技术上可以，但没必要。天地图的定位偏政务和测绘场景，它的 JS SDK 在小程序里的适配、文档完整度、社区活跃度都远不如微信生态内的腾讯位置服务。我用的是腾讯位置服务微信小程序 SDK，申请一个 key，在小程序后台配置 request 合法域名，然后就能用它的逆地址解析（把经纬度转成文字地址）、关键词搜索（搜“停车场”）、选点组件（发布车位时在地图上点选坐标）。选点这个功能很关键，发布车位不是让你手填地址，而是拉一个地图，定位后长按选点，自动填出地址。实现上就是引入腾讯位置服务的map组件 +qqmap-wx-jssdk，监听bindtap拿到经纬度，再调 reverseGeocoder 换地址。
距离计算有两种做法：一种是列表页直接用云开发的 geoNear 按距离排序，这个在2.2里提过；另一种是如果后端不是云开发，前端要拿到目标点经纬度后自己算距离。前端算距离用 Haversine 公式就可以，网上代码很多，核心是处理经纬度弧度换算。建议两种方法都了解，答辩老师大概率会问“用户离车位多远，怎么算的”。
地图组件有一个经典坑：它在真机上的层级问题。map 是老牌的原生组件，在部分手机上层级高于普通 view，你在地图上盖一个搜索框、按钮，可能会被地图盖住。后来官方改成同层渲染了，但碰到老机型还是要留意。我的处理方式是：搜索框不用绝对定位盖在地图上，而是放在地图上方作为普通布局的一部分，需要浮动的按钮用cover-view来写。这一点写在论文“系统实现”里，说明你有真机兼容意识。
3.2 网络层封装与登录态管理
云开发模式下，前端不是直接调 wx.request 请求后端，而是调用云函数，但业务上依然有统一的请求入口问题。我的做法是封装了一个cloud.js，统一处理云函数调用，里面集中做加载态、错误处理、登录态校验。
// utils/cloud.js const callFunction = (name, data = {}, showLoading = true) => { if (showLoading) wx.showLoading({ title: '加载中', mask: true }); return wx.cloud.callFunction({ name, data }) .then(res => { if (res.result && res.result.code === 0) { return res.result.data; } else { wx.showToast({ title: res.result.msg || '请求失败', icon: 'none' }); return Promise.reject(res); } }) .catch(err => { wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' }); return Promise.reject(err); }) .finally(() => { if (showLoading) wx.hideLoading(); }); }; module.exports = { callFunction };登录态不要用云开发默认的 openid 直接当业务用户ID用。我在 users 表里用 openid 创建了用户记录，然后额外生成一个自增的 user_id 作为业务主键，下单、评论、余额操作都引用 user_id，这样以后就算不是用微信云开发，或者要对接其他登录方式，用户体系也不用推倒重来。登录流程写在 app.js 的 onLaunch 里：先wx.cloud.init，再调云函数login，云函数里通过cloud.getWXContext()拿到 OPENID，查 users 表，不存在就创建，返回用户数据，前端放进全局 globalData。
热词里有人问“base64解码 atob 函数用不了”，这个问题在小程序里很常见。因为小程序的 JS 引擎不是完整浏览器环境，全局没有 atob/btoa，但是微信提供了wx.base64ToArrayBuffer和wx.arrayBufferToBase64，做 Base64 与 ArrayBuffer 互转时要用这两个原生 API。这个看下来是小程序开发的通用性问题，但如果你在停车位项目里要做图片压缩后转 Base64 上传，就会碰到。
3.3 自定义导航栏与 iPhone 适配
停车位平台顶部会放一个搜索框，“搜索附近停车场”、“输入目的地”，如果用小程序的默认导航栏，就不能在顶部塞自定义内容。所以我好几个页面都用了自定义导航栏：在 app.json 里设置"navigationStyle": "custom"，然后在页面顶部自己画一个导航栏，左侧返回箭头，中间标题或搜索框。
自定义导航栏最麻烦的是适配。iPhone 有状态栏和底部横条，安卓各厂商状态栏高度还不一样。取高度用这两个 API：
const { statusBarHeight } = wx.getWindowInfo(); const menuButton = wx.getMenuButtonBoundingClientRect(); const navHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height;这段代码的意思是：胶囊按钮（右上角那个 ... 和 ◎ 按钮）的高度加上它到状态栏的距离，乘以2，就是导航栏的安全高度。因为胶囊按钮设计的垂直中心基本等于状态栏到底部内容的安全中心，所以用这个公式能算出导航栏的合适高度。注意在页面 onLoad 里取，不要在 app.js 里取完存起来，有的安卓机上 app.onLaunch 时窗口信息还不准确。
拿到的 px 值在 wxml 里可以直接用style="height: {{navHeight}}px"设置，不需要转 rpx。因为导航栏高度是跟设备物理像素相关的，px 才是最终渲染单位。我见过很多同学在这里踩坑，把 px 转成 rpx 再转回来，结果所有机型都偏了。
还有个热词说“微信小程序顶部导航栏高度”，说明这是普遍痛点。记住一个公式就够：导航栏高度 = (胶囊top - 状态栏高) * 2 + 胶囊高。这个公式在所有主流机型上实测都是准的。
3.4 发布车位表单与组件细节
发布车位页面是表单交互最复杂的页面。要填车位地址（地图选点）、上传照片、选车位类型（地上/地下）、设置时段价格、选择是否支持月租。这里面 radio 组件经常被问，因为默认样式太丑，你要自定义。微信小程序的 radio 是原生组件，想改样式有两种思路：一是用radio-group+radio，然后通过 CSS 的:checked伪类覆盖圆点颜色和大小；二是干脆不用 radio，自己用 view 实现一组选项，点击时切换状态，视觉上更可控，逻辑也简单。
我实际用的是第二种，因为停车位类型未来可能扩展成“地面/地下/立体/专属”更多选项，自己写 view 更灵活。表单校验我放在提交时统一做，不做一个字段一个弹窗，因为体验太碎。提交后调云函数写入 parking_spots，同时把照片上传到云存储拿到 fileID，再回填字段。注意顺序：一定要先传图片，拿到 fileID 再提交表单数据，否则数据里引用的图片地址是空的。
上传图片用wx.chooseMedia选图，然后wx.cloud.uploadFile。照片压缩我用了wx.compressImage，因为小程序云存储有大小限制，手机拍的原图动不动几兆，直接传会失败。压缩到800px宽、质量80%，车位照片足够清晰，上传速度也快。这些细节写进论文“性能优化”一节，非常加分。
3.5 分包与启动性能优化
做完一版功能后，我发现主包体积逼近2MB限制。微信小程序主包限制2MB，总包限制20MB（现在有更多）。停车位平台的页面不算特别多，但地图SDK、图片资源、公共组件堆一起很容易超。解决方案是分包：把“发布车位”、“订单详情”、“我的钱包”这些非首页页面放进 subpackages，主包只保留 tabBar 页面和公共工具。
分包的坑集中在“分包异步化”上，热词里“微信小程序 分包异步化 在其它分包中的插”说的就是跨分包引用问题。默认情况下，分包A不能直接 require 分包B里的模块，必须用require.async等异步加载：
const module = await require.async('../../packageB/utils/biz.js');如果不等异步返回就直接用，会报错，而且表达式看起来是正常的，因为是 Promise 需要 await，很多人漏掉 await 导致白屏或者 undefined。所以我的经验是：项目里尽量把公共逻辑提到主包的 utils 里，不要跨分包引用。页面之间跳转用路径，不互相 import 模块，这样分包边界清晰，也不容易踩到异步化的坑。
分包还有一个副作用：按需加载会导致页面切换时短暂的白屏，特别是在低端安卓机上。停车位列表页如果涉及地图组件，首次加载会比较慢。我的优化是三个：列表页提前wx.preloadPage预加载分包页面、图片全部用懒加载lazy-load、地图组件初始化时先显示一个白色的加载占位。这些优化工作量不大，但演示时会明显顺滑。
4. 测试、真机调试与常见问题排查
4.1 真机预览白屏问题排查思路
“真机预览正常，开发者工具白屏”、“PC端微信小程序白屏”、“tab切换白屏一瞬间”，这些都是开发群里高频出现的问题。我在项目里也踩过。总结下来，白屏基本逃不出这几类原因：
- 基础库版本不一致。开发者工具里的基础库版本可能和真机上的不一样，地图、cover-view、分包异步化这些能力的表现都受基础库影响。排查时先在开发者工具里切换到和真机一致的版本。
- 缓存问题。微信开发者工具的缓存偶尔会异常，导致改完代码刷新不生效或直接白屏。我遇到“诡异白屏”时，第一招就是清缓存重编译，能解决一半问题。
- 分包异步加载失败。页面引用了分包外的资源或变量，启动时没有拿到数据，导致渲染空白，而且控制台不一定报错。
- 地图组件初始化失败。在小程序里 map 组件如果 key 没配好、定位权限没弹窗，组件会整块空白，看起来像页面白屏。
排查手段就是拿真机数据说话。在app.js的 onError 里加日志上报，把错误信息记录到云开发的日志服务里，然后在真机上复现，看日志。另一个手段是打开真机调试时点开 vConsole，看有没有报错和网络请求失败。不要毫无头绪地改代码，很容易把好的改坏。
4.2 抓包工具在调试中的应用心得
开发过程中排查接口问题，抓包是必不可少的手段。微信开发者工具自带 Network 面板，但真机上的问题（比如手机网络环境、HTTPS 证书校验、请求被劫持）抓不到，就需要用抓包工具。我用过 fidder 和 reqable。原理都一样：手机和电脑连同一个局域网，手机设置代理指向电脑 IP，然后在电脑上装根证书，就能看到小程序的 HTTPS 请求内容，包括请求头、请求体、响应体。
这里说一个我的经验：抓包不只是“看请求”，更多是用来判断“这个 bug 是前端还是后端的问题”。比如订单状态不对，我先抓包看用户点按钮后发出去的参数对不对，如果参数对、后端返回也正常，那就是前后端数据交互 UI 处理问题；如果参数本身不对，那就是前端传参的锅。有次用户反馈“支付成功后订单还是待支付”，我抓包发现是云函数支付回调里把字段名写错了，前端传 payment_status，后端读 status，这个 bug 在代码 review 时完全看不出来，抓包一眼就看出来了。
不过抓包在真机上要装证书，调试结束后记得关闭代理。曾经我把手机代理忘了关，导致第二天小程序直接连不上网，检查半天才发现是代理残留。这个细节也提醒一点：日常开发时尽量用微信开发者工具的 Network 面板，遇到真机问题再用抓包，能少惹很多麻烦。
4.3 常见问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 开发者工具白屏 | 基础库版本不一致/缓存异常 | 清缓存、切换基础库版本 |
| 真机地图不显示 | map key 未配置或 request 域名未设置 | 检查腾讯位置服务配置 |
| 自定义导航栏高度不对 | 只取了 statusBarHeight，未计算胶囊按钮 | 用 (胶囊top - 状态栏) * 2 + 胶囊高 |
| 上传图片失败 | 图片太大超出存储限制 | 先用 wx.compressImage 压缩 |
| 跨分包引用模块报错 | 直接 require 了别的分包 | 用 require.async 或把公共代码移到主包 |
| 支付成功但订单状态没更新 | 回调字段名不一致 | 抓包看回调参数 |
| 用户预约成功但车位主没收到通知 | 订阅消息未配置模板 | 检查订阅消息模板ID |
| 数据库查询执行慢 | 集合没建索引 | 在云开发控制台为查询字段建索引 |
4.4 论文结构、图表规范与答辩准备
论文这部分，很多人觉得是“写作文”，但实际上它有很强的结构逻辑。我的论文目录大致是：
- 摘要、Abstract
- 第1章 绪论（背景、国内外研究现状、研究内容）
- 第2章 相关技术介绍（微信小程序、云开发、腾讯位置服务）
- 第3章 系统需求分析（可行性分析、功能需求、非功能需求）
- 第4章 系统总体设计（架构设计、功能模块划分、数据库设计）
- 第5章 系统详细实现（每个模块的页面截图+核心代码+实现说明）
- 第6章 系统测试（功能测试用例、性能测试、兼容性测试）
- 第7章 总结与展望（项目完成情况、不足、后续改进方向）
图表是论文颜值的关键。我的经验是：用例图、ER图、流程图、系统架构图这四个必须有，而且不要用截图充当。画图工具用 processon 或者 draw.io 都可以，最重要的是保持同一套配色和线宽，看起来专业。比如订单状态机我画了一张状态流转图，答辩老师看了之后直接说“这个设计得很清楚”。
答辩常见问题，提前准备会有很大优势：
- “为什么选微信小程序？”答：轻量、免安装、社交传播属性强，符合共享停车C端用户的使用习惯。
- “为什么用云开发而不是自建后端？”答：云开发免运维、天然支持微信登录，适合快速验证产品，且云函数支持计算，项目规模可控。如果强调自己后端能力，可以补一句“预留了自建后端接口的切换空间”。
- “订单并发怎么处理？”答：车位状态更新使用云数据库的事务操作或原子更新，避免两个用户同时预约同一个车位。云开发数据库支持事务，但要注意事务内不能有网络请求，要把所有读写操作都放在事务对象上。
- “定位精度如何保证？”答：采用微信自带定位API获取用户经纬度，结合腾讯地图逆地址解析；停车位坐标由车位主在地图上选点生成，比纯手填地址更精确。
- “支付安全性怎么保证？”答：支付签名在服务端云函数完成，前端不接触商户密钥；支付结果以微信支付回调为准，不信任前端回调。
写论文的一个坑：技术方案不要大段贴官方文档，查重率会很难看。核心算法和设计思路用自己话重新组织，配合自己在项目里真实的截图和运行数据，才不会被查重系统误判。
关于查重，我的经验是：论文初稿先按照自己理解写，写完再对照官方文档补细节，而不是先抄文档再压缩。前一种写法写出来的内容更像“我的方案”，后一种怎么写都像“抄的”。
5. 项目做完了，回头看这几点最值得记住
停车位共享平台这个项目，从去年开始做到现在，有一个特别明显的感觉：毕设项目能不能做好，不在于你用多“高级”的框架和算法，而在于能不能把一个业务闭环完整地跑通。从用户登录、地图找位、预约下单，到支付结算、信用分、管理员审核，每个环节都通，这个项目就是完整的。很多同学到最后交出来一个只有几个静态页面的“小程序”，就是因为陷在“我要做一个很牛的功能”里，忽略了业务闭环。
再分享一个小技巧：答辩前，一定要准备一套演示数据。比如在数据库里预置几个附近的车位、几条不同状态的订单、一个待审核的车位主申请。演示的时候按“找车位 -> 下单 -> 开始停车 -> 结算 -> 查看订单”这个顺序走，不要东点一个西点一个，评委跟着你的节奏走，答辩效果会好很多。我当时演示的时候还特意用了模拟器里的“改变定位”功能，提前把用户位置设置到停车位附近，省得现场等定位。这类看起来不起眼的准备，往往是答辩顺利的关键。
这个项目后续还可以扩展的方向也有不少：接入真正的微信支付商户号完成在线支付闭环、增加车位预约的智能推荐算法、加入物联网地锁实现车位硬锁定、做一套基于用户信用分的动态定价系统。这些不一定要在毕设阶段全部做完，但写在“总结与展望”里，就是一个很有说服力的收尾。
本文还有配套的精品资源，点击获取
