Java+Spring Boot实现同城汽修系统，小程序/H5/公众号三端闭环

做同城汽修系统这个方向，我从去年开始就一直在折腾。原因也很简单：身边一位开汽修店的朋友，每天被电话预约、纸质开单、技师派工搞得焦头烂额，客户资料全堆在微信聊天记录里。这套基于 Java 的同城汽车维修/汽车改装系统源码，支持小程序、公众号、H5 三端，恰好把预约、接单、施工、结算、评价、会员这套完整流程从线下搬到了线上。如果你正好在找同城服务类的项目参考，或者想找一个能跑通完整业务闭环的 Java 项目来练手，这篇内容可以给你省下不少自己摸索的时间。

先说明一下这套系统的定位：它不是那种纯玩具级的学习 Demo，而是面向真实门店业务的工程化代码。后端用 Java 做主力，Spring Boot 是主框架，前端覆盖微信小程序、微信公众号网页版、H5 三个入口，一套后端接口逻辑服务三端。系统里包含了门店管理、技师管理、服务项目、订单状态机、LBS 门店匹配、微信支付、会员卡、优惠券、积分商城等模块。对于想接同城汽修外包或想转型做同城服务平台的开发者，这套源码的模块拆解方式很有参考价值。

整个项目我拆开看了一遍，下面从业务设计、技术实现、部署过程、踩坑记录、二开方向这五个维度，整理成一篇可以直接照着操作的经验帖。

1. 项目整体设计与业务场景拆解

1.1 同城汽修到底在解决什么需求

汽车维修不是标准商品交易，它是典型的“非标服务”。换个机油和做全车钣金喷漆，从工时、价格到技术难度完全不是一个量级。所以汽修系统的核心不是“卖货”，而是把一套预约、报价、施工、验收的流程理顺。

这里踩过一个业务认知上的坑：一开始我以为核心功能是商城，实际跑下来发现，门店端真正高频的痛点是三件事：

• 客户预约到店时间不透明，前台靠电话反复确认；
• 技师派工靠喊，单子多了根本没有统一调度；
• 施工完成后没有照片留底，客户不满意时说不清楚。

这套源码的设计思路正好围绕这三点展开。用户在 H5 或小程序选择服务项目，填写车辆信息和预约时间，订单进入待接单状态。门店后台可以看到所有订单，按距离和时间排序，店长指派技师接单。技师施工过程中可以上传施工前、施工后照片，客户在订单详情页能直接看到。这不只是把纸质单换成电子单，而是让整个服务过程可验证、可留痕。

汽车改装业务和维修还不太一样：改装更重“方案报价”和“案例展示”。源码里把服务项目分成了普通维修项目和改装项目两种，改装项目支持填写工时费、材料费、效果图多张，客户确认报价后才进入施工队列。这种设计比较符合门店真实习惯，因为改装客户最在意的是施工效果和价格明细。

1.2 为什么选择三端同步而不是只做小程序

很多同城服务项目一开始只做小程序，这套源码是三端都做了，这在业务逻辑上是站得住的。

小程序适合高频轻量操作：预约、查看订单、分享卡片、接收服务通知。它的传播链路很短，在微信里点开即用，不用下载 App。但小程序的限制也很明显：跳转外部链接受限、微信内部封禁规则复杂、内容沉淀能力弱。公众号恰好弥补了这些短板。门店可以发布保养攻略、改装案例、优惠活动，通过公众号菜单直接拉起 H5 页面完成预约。H5 的意义在于“一稿多投”：它可以被嵌入公众号图文、投放信息流广告、甚至内嵌到自建 App 的 WebView 里。

从开发角度来说，三端共用一套 Java 后端接口，业务逻辑只维护一份。前端方面，小程序和 H5 页面如果长得很像，大概率是基于 uni-app 这类跨端框架写的，或者前端各写一套但接口完全对齐。无论哪种方式，只要后端接口的返回结构统一，新增一个端的成本主要在前端页面，不涉及后端改造。

实际业务里，三端是这么配合的：一位车主在公众号看到一篇夏季空调保养攻略，文末的 H5 预约卡片直接跳转到预约页；预约完成后公众号推送服务通知；到店施工期间，技师上传的施工照片在小程序端实时可见。这三端各司其职，不是一个端替代另一个端的关系。

1.3 源码里的核心角色与权限体系

这套源码的角色模型很直观，分四类：

• 车主端用户：通过微信授权登录，可以提交预约、查看订单、领取优惠券、充值会员卡、评价服务。
• 门店员工端：包含店长和技师，店长可以接单、派单、修改报价、处理退款；技师可以更新施工状态、上传施工照片。
• 平台运营端：查看所有门店的经营数据、订单流水、客诉记录，可以上下架服务项目。
• 超级管理员：管理门店入驻、员工账号、系统配置、数据库备份。

权限这块用了经典的 RBAC 模型（用户-角色-菜单），数据表也就四张：用户表、角色表、菜单表、用户角色关联表。对于这套规模的系统，RBAC 是最稳的选择，不需要引入 Shiro 或 Spring Security 那套复杂的东西，自定义一个拦截器加注解校验就能覆盖所有接口的权限控制。我试过，简单直接，二开的时候也容易看懂。

整个订单流转是这样串起来的：车主提交预约 → 门店接单 → 技师报价 → 车主确认 → 到店施工 → 技师上传完工图 → 车主验收 → 结算完成 → 评价。这套流程是汽修业务的主干道，所有其他功能都是围绕它来服务。

2. 技术选型与核心模块实现

2.1 Java 后端的主流搭配：Spring Boot + MyBatis + Redis

这套源码的 Java 后端技术栈非常主流，没有花里胡哨的东西。Spring Boot 负责依赖管理和自动配置，Web 容器内置 Tomcat，打包成 jar 直接运行，部署成本低。MyBatis 作为持久层框架，SQL 自己控制，订单这类复杂查询场景反而比 JPA 更好排查问题。如果源码里有大量单表 CRUD，大概率会配合 MyBatis-Plus，这一点二开时可以看实际依赖。

Redis 在这套系统里承担了几件关键事：

• 短信验证码缓存，设置 5 分钟过期；
• 微信接口 access_token 缓存，避免频繁调用微信接口导致限流；
• 门店经纬度坐标缓存，用于附近门店匹配；
• 部分热点服务项目的浏览量统计，异步累计后刷入数据库。

数据库用 MySQL，核心表按业务域划分，大致包括用户表、门店表、服务项目表、订单表、订单明细表、技师表、会员卡表、优惠券表、积分流水表。以订单表为例，核心字段基本围绕订单号、用户 ID、门店 ID、技师 ID、服务项目 ID、订单状态、实付金额、优惠金额、预约时间、开工时间、完工时间、创建时间、更新时间来设计。这里我特别说一下订单号：建议用“日期 + 随机序列”生成，不要用数据库自增主键直接透出，否则订单信息容易被遍历。

2.2 三端技术方案的取舍：uni-app 还是原生

很多开发者拿到源码后会纠结一个事情：前端用的是什么方案，我能不能改？从实际项目经验看，汽修这类系统最合适的搭配是：

• 小程序端用原生 WXML 或 uni-app；
• 公众号端直接做 H5 页面，在微信内置浏览器打开；
• H5 端用 Vue 技术栈打包后部署到 Nginx。

如果这套源码的小程序和 H5 看着像同一套页面结构，大概率用了 uni-app，好处是一套代码编译到多端，开发效率高。但代价是某些微信原生能力需要条件编译处理，比如 web-view 组件、微信支付参数获取方式在不同端有差异。

如果源码是分开写的（小程序一套独立代码，H5 一套独立代码），那接口一致性就显得格外重要。后端接口统一返回 code + msg + data 的结构，前端拿到 code 统一做拦截处理，比如登录失效跳转登录页。无论哪种方案，二开时有一条铁律：不要轻易改后端接口的出入参格式，否则三端全要跟着动，工作量翻倍。

2.3 订单流程与同城 LBS 定位的代码逻辑

同城是这套系统的一个关键词。没有 LBS 能力，同城就无从谈起。整套 LBS 逻辑分为三块：

第一，前端定位。小程序端通过 wx.getLocation 获取用户经纬度，H5 端通过微信 JS-SDK 获取定位。这里有一个踩坑点：微信 JS-SDK 获取定位需要用户手动授权，并且必须在 config 接口中传入正确的签名，否则定位直接失败。

第二，后端匹配门店。拿到用户经纬度后，后端用 Haversine 公式计算用户与所有门店的距离，按距离升序返回附近的可用门店。原理上就是用经纬度算球面距离，代码实现也不复杂。实际项目中门店数量通常只有几十到几百家，全表计算完全没压力。

1. 用户触发定位，前端把经纬度传给后端；
2. 后端从缓存读取门店坐标，逐店计算距离；
3. 按距离排序后，返回前 10 家门店列表。

第三，门店接单展示。门店后台看到的待接订单按距离排序，同时显示用户填写的服务描述、计划到店时间。这样店长可以根据技师空档和距离决定是否接单。

订单状态机这部分我单独强调一下，因为它是整个系统的核心骨架。状态流转一般是：待支付 → 待接单 → 已接单 → 施工中 → 待验收 → 已完成 → 已取消。如果涉及售后，还有售后中状态。代码层面建议用枚举管理状态，不允许跨级跳转，比如未支付订单不能直接进入施工中。定时任务负责扫描超时未支付订单自动关闭，超时未接单的订单自动提醒店长处理。

2.4 支付与会员营销模块的设计

支付这块对接的是微信支付。流程不复杂，但细节容易出错。常规链路是：后端调用微信支付统一下单接口，拿到 prepay_id 后生成调起支付的参数返回前端；前端 wx.requestPayment 调起微信支付；支付完成后微信异步回调后端接口，后端验签后更新订单状态。

这里最容易踩的坑是回调幂等。正常情况下，微信支付回调可能因为网络原因重复推送，如果不做幂等处理，订单状态会被重复更新，甚至可能给用户重复加积分。我的建议是：回调处理时先根据订单号查业务状态，如果已经是“已完成”状态就直接返回成功，不再做任何更新。

会员营销层面，这套源码提供了储值卡、次卡、优惠券、积分商城、分享有礼这些模块。做这类功能时我的原则是：先做核心三种——新人优惠券、储值卡、积分兑换，凑单和拼团这类玩法等核心交易闭环跑通后再上。因为营销功能越多，对账复杂度越高，后期排查问题的成本也越大。

3. 系统部署与上线实操记录

3.1 从源码到跑起来的完整操作流程

我按实际部署一套三端项目经验来梳理这个流程。技术栈环境先列清楚：

• JDK 8 或者 JDK 17（看源码里 Spring Boot 版本定）；
• Maven 3.6+；
• MySQL 5.7 或 8.0；
• Redis 5.0+；
• Nginx（部署 H5 和反向代理后端接口）；
• 微信小程序开发者工具（导入小程序前端工程）。

拿到源码后，我不建议直接急着启动，先把目录结构理一遍。一般源码会分成 admin（后台管理）、api（用户端接口）、wx-mp（小程序）、h5（H5 页面）等几个模块。先看 README 或 config 目录，确认数据库脚本的位置。

第一步，初始化数据库。用 Navicat 或命令行 source 导入 SQL 脚本，按顺序执行，先建库再导表。如果脚本里有初始化数据，比如系统管理员的账号密码、默认服务项目，一并导入，这样后台登录才测得了。

第二步，改配置文件。核心是 application.yml 里的数据源、Redis 连接、微信小程序 AppID/AppSecret、公众号 AppID/AppSecret、支付商户号相关配置。这里要注意：如果本地测试，配置文件里的小程序 AppID 可以用测试号，但支付参数必须用真实商户号或者改成沙箱模式，否则支付流程走不通。

第三步，启动后端服务。本地开发可以用 mvn spring-boot:run，也可以先 mvn clean package -DskipTests 打包成 jar，再 java -jar xxx.jar 启动。启动成功后，先测几个不需要微信授权的接口，比如获取服务项目列表、门店列表。接口没问题，再测微信登录链路。

第四步，跑前端。H5 工程如果是 Vue 项目，先 npm install，然后 npm run dev 本地联调。小程序工程用微信开发者工具导入，在工具里配置后端接口地址。需要注意：微信开发者工具本地调试时，要在“详情-本地设置”里勾选“不校验合法域名”。

第五步，上线部署。把后端 jar 部署到服务器，H5 打包产物放到 Nginx 静态目录，小程序发布前在小程序后台配置服务器域名。

3.2 小程序、公众号、H5 三端关键配置对照

这是我整理的一份三端配置对照表，实操时可以直接对着填。

三个端配置里最容易搞混的是“网页授权域名”和“JS 接口安全域名”。微信公众号里，如果 H5 页面要获取用户 OpenID，就需要配置网页授权域名；如果 H5 页面要调用定位、分享等 JS-SDK 能力，就需要配置 JS 接口安全域名。两者分别控制不同能力，不能只配一个。

小程序跳转 H5 的时候，还要注意业务域名的问题。小程序后台要配置业务域名，并且把校验文件放到 H5 域名的根目录下。很多人卡在这里，明明域名叫对了，小程序里 web-view 还是白屏，大概率是校验文件没放到服务器根目录，或者域名配置生效有延迟。

3.3 部署过程中的资源规划与性能参数

很多入门开发者容易忽视资源规划。我建议初期就用 2 核 4G 的云服务器，把后端、MySQL、Redis、Nginx 都放一台机器上。这个配置撑得住几百家门店、几千个日常订单，完全没问题。等用户量上来了，再把 MySQL 和 Redis 拆分到独立机器。

后端启动的 JVM 参数我建议显式指定，避免服务器默认内存参数不符合实际。常用的配置如下：

bash复制java -Xms512m -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs -jar xxx.jar

-Xms512m 设置初始堆内存，-Xmx1024m 设置最大堆内存。HeapDumpOnOutOfMemoryError 这个参数强烈建议加上，一旦发生内存溢出，JVM 会自动 dump 堆现场，方便排查。如果不加，线上 OOM 之后连日志记录都没有，只能靠猜。

数据库连接池方面，如果源码用的是 HikariCP，默认最大连接数 10 通常够用。如果用的是 Druid，建议把最大活跃连接数控制在 20 以内，避免连接数设置过高反而不稳定。这里需要强调：连接池的 maxActive 不是越大越好，过大反而会拖垮数据库。以 2 核 4G 的服务器为例，MySQL 的最大连接数配置 100 就足够了。

图片上传属于比较容易踩坑的地方。汽修系统里施工照片、门店照片、改装案例图都很大，如果把图片存到数据库或存到应用服务器的本地磁盘，后患无穷。建议直接用对象存储 OSS/COS，前端直传或后端转发都行。如果用宝塔面板部署 H5，Nginx 配置里要注意静态资源的缓存策略，图片类资源设置 30 天强缓存，前端 js/css 文件设置协商缓存，能减少不少服务器压力。

4. 高频踩坑问题与排查实录

4.1 微信生态内嵌页跳转与登录态问题

微信生态里的技术债，大部分集中在“页面跳转”和“登录态”这两件事上。我遇到的第一个坑就是小程序跳转 H5 页面打不开。现象是小程序里用 web-view 组件加载 H5 页面，页面白屏。排查下来原因很简单：小程序后台的业务域名没有配置，或者校验文件没有放到 H5 服务器的根目录。这个问题可以说是小程序 web-view 最常见的问题，没有之一。配置路径是：小程序后台 → 开发管理 → 开发设置 → 业务域名，填域名后下载校验文件，放到域名根目录，确认可通过 https://你的域名/校验文件 访问。

第二个坑是公众号图文里嵌入 H5 链接，用户点击后提示“链接内容不属于当前公众号”。这个提示是因为微信对公众号图文内链做了域名校验，链接域名不在公众号后台配置的 JS 接口安全域名或网页授权域名范围内。解决办法是：在公众号后台把链接域名加到“JS 接口安全域名”里，并且那个校验文件同样要放在域名根目录。另外，如果使用临时链接或带特殊参数的链接，也可能触发这个提示，建议用稳定域名加固定参数。

第三个坑是 H5 页面在微信内获取用户登录态。H5 页面通过公众号网页授权获取用户 OpenID 时，回调地址的域名必须和公众号后台配置的“网页授权域名”完全一致，包括 http/https 协议、端口、路径前缀。很多项目本地调试没问题，一旦部署到服务器就登录失败，几乎都是因为回调域名不一致。

第四个坑是登录态跨端传递。小程序打开 H5 页面时，如果要让 H5 复用小程序的登录态，有几种方案：最简单的是在 web-view 的 URL 上拼 token 参数，H5 页面拿到 token 后调后端接口换取用户信息。但把 token 放在 URL 里有一个风险：token 会出现在访问日志中，也可能被分享链接带出去。更稳妥的做法是 H5 页面自己在 URL 上带一个一次性 code，后端换 token，并且 token 支持短期会话。如果对安全性有要求，建议在 H5 端再走一次微信网页授权，用 unionid 打通用户身份，而不是直接传 token。

4.2 JVM 内存溢出与第三方组件编译报错

上线一段时间后，最容易遇到的就是 OOM。java: outofmemoryerror: insufficient memory 这类报错在日志里出现时，先不要急着加内存，先看代码逻辑。

常见原因有三个：

• 一次性查询数据量过大：比如导出报表时一次性把一个月订单全部查出来放在内存里，数据量上来后直接 OOM。解决办法是分批查询并逐步写入文件，或使用数据库流式查询游标。
• 图片处理失败：上传图片后直接转为 Base64 字符串放在内存，大图会造成内存暴涨。解决办法是直接存储文件地址，不要在内存中做额外的转换。
• Redis 连接池或数据库连接池泄漏：连接未释放，长期运行后线程池耗尽。排查时用 jstat -gc pid 看 GC 情况，再用 jmap -heap pid 看堆内存使用。

如果堆内存确实不够，可以先调整 JVM 参数。比如从 -Xmx512m 调整到 -Xmx1024m，同时配合 HeapDumpOnOutOfMemoryError。但注意，增加堆内存只是临时手段，根本解法还是优化代码中的内存占用。

另一个高频编译问题是 Lombok 报错。比如 you aren't using a compiler supported by lombok, so lombok will not work。这个报错通常发生在 JDK 大版本升级后，项目中 Lombok 版本太老，不支持新版本编译器的内部 API。解决办法是升级 Lombok 版本到 1.18.20 以上，或降低 JDK 版本。还有一种情况是 IDE 里没有启用注解处理，在 IDEA 的 Settings 中勾选 Enable annotation processing 即可。如果项目同时用到了 MapStruct 这类注解处理器，Lombok 和它共用时需要在 Maven 的 annotationProcessorPaths 里同时声明两者，并注意顺序。

4.3 公众号 H5 和小程序之间数据打通的设计

很多运营方希望用户在公众号里看内容、在小程序里下单，但两边用户数据是割裂的，这就要解决数据打通的问题。

最好的方案是使用微信开放平台账号体系。同一个开放平台账号下，如果小程序和公众号绑定在一起，同一用户在不同端获得的 openid 不同，但 unionid 一致。所以用户表设计时，建议加 unionid 字段，并建立唯一索引。这样无论用户从哪个端进来，只要 unionid 相同，后端都能识别为同一个用户。

但 unionid 不是永远都能拿到的。如果没有绑定开放平台，或者用户没有关注公众号，就只能靠手机号关联。这也是这类系统都要做手机号绑定功能的原因。具体设计逻辑是：H5 端用户完成微信公众号授权登录后，小程序端再次登录时，如果检测到当前用户 unionid 与已有用户一致，直接合并账号；如果不一致但手机号相同，可以设计一个“账号合并”流程，让用户输入手机验证码确认后合并数据和订单记录。

还有一个常见的分享裂变需求：用户 A 在公众号里看到 H5 页面，把 H5 链接分享给微信好友 B，B 打开后直接进入小程序，但是 A 的邀请关系要带上。实现方式有两种：一种是在 H5 链接上带邀请码参数，H5 页面保存邀请码到后端，再跳转小程序时通过 URL Scheme 传递；另一种是小程序分享卡片上直接带 query 参数，落地页做关系绑定。这两种方式里，小程序分享卡片的方式更稳定，因为 H5 跳小程序本身有较多限制，不是所有场景都支持。

5. 二开扩展方向与个人经验总结

5.1 从汽修到同城服务可复用的扩展方向

跑完这套汽修系统后，你会发现它的核心价值不只是“修车”，而是把“同城上门/到店服务”的通用交易链路做出来了。所以二开的方向可以放得很宽：

• 洗车美容：增加服务时长、排队叫号、储值次卡的功能；
• 上门保养：增加技师 LBS 打卡、上门服务轨迹记录；
• 家电维修：增加故障描述表单、维修配件收费明细；
• 开锁/疏通：增加紧急单优先派单逻辑、价格区间预估算；
• 年检/保养提醒：根据车辆注册日期或保养里程，通过公众号模板消息或小程序订阅消息推送提醒。

这些功能里，我个人最推荐优先做的是“秒报”和“年检提醒”。秒报的逻辑是：车主填写故障描述和期望到店时间，多个门店在线报价，车主选择报价合适的门店下单。这个功能能大幅提高订单转化率，因为用户体验是“发了需求就有多家店响应”，比传统的“找店-打电话-问价格-再下单”顺畅很多。做的时候可以复用现成的订单状态机，在“待接单”之前加一个“待报价”状态，门店技师填写报价后进入“待接单”状态。

5.2 这套源码适合谁用、怎么用最划算

如果你是自己开汽修店/改装店，想快速搭建一套线上预约系统，我建议不要一开始就把所有功能都铺上去。先把核心四件事做好：服务项目列表、预约下单、会员储值、消息通知。其他功能（积分商城、拼团、达人分享）等日常经营真正有需求了再加。

如果你是接外包项目的开发者，这套源码的作用是当“基座项目”。同城服务类的需求七成都是相似的，能复用就不要从零写。接单时拿着这套源码做演示，给客户看三端实际效果，比任何 PPT 都有说服力。而且基于现有代码改造成本低，报价上就有竞争优势。

如果你是 Java 学习者，这套系统是一个非常好的“考研项目”。平时背的 java 面试八股文，比如 Redis 缓存、JWT 登录、微信授权、订单状态机、支付回调幂等、分布式锁，几乎都能在代码里找到实际落地的位置。一边看代码一边想“为什么这么写”，比死记硬背效率高得多。

有一点要特别提醒：不管源码是买来的还是开源的，商用之前一定确认授权协议。如果是有偿授权，注意授权的域名数量和并发限制，避免上线后发现授权不合法。

我在实际搭建这类三端项目的最大体会是：三端项目最怕的不是业务逻辑难，而是配置混乱。小程序 AppID、公众号 AppSecret、服务器域名、支付商户号，这几处配置哪怕错一个，登录和支付链路都会卡住。我的习惯是先在文档里画一张配置清单表，把三端所有配置项提前列好，确认无误后再动手部署。联调顺序建议是：后端接口自测 → H5 页面联调 → 公众号授权联调 → 小程序联调 → 支付回调联调，按这个顺序走下来，问题定位会快很多。这套系统把同城汽修的骨架搭得挺完整，真正要出效果，还是得靠二开的人把线下服务细节和线上流程对齐，慢慢打磨。