Go微服务同城家政上门预约系统源码架构拆解与部署实战

技术栈总览

整套系统采用前后端分离设计，核心通信基于 RESTful API 与 WebSocket 长连接。后端使用 Go 语言配合 Gin 框架，通过 GORM 操作 MySQL 8.4，鉴权由 JWT 接管，服务配置统一走 Viper。前端分成三部分：用户/技师端基于 uni-app + Vue 3 开发，一套代码可编译为微信小程序、H5 及 App；管理后台则是纯 Vue 3 + TypeScript + Vite + Arco Design 的组合。这种分层让团队接手后不必在跨端兼容上耗费额外精力。

前端架构与多端适配

用户端与技师端完全共享 uni-app 工程，所有页面数据和交互逻辑通过 api 目录下的 service 层与后端对接。地图能力依赖腾讯位置服务，下单时的定位、逆地址解析、地图选点都封装成可复用模块。首页轮播图、推荐服务、推荐技师等模块全部由管理后台的可视化装修组件驱动，运营人员调整版面时不会触动业务代码。管理后台采用 Arco Design 组件库，配合 Pinia 做全局状态管理，权限控制和菜单渲染逻辑清晰，团队二开时增减功能入口非常直接。

后端服务设计

服务主框架选型 Gin，路由分层清晰，接口权限、参数校验、业务处理与订单状态机都分布在不同的包中。订单状态的流转（待接单、已出发、服务中、待验收等）通过统一的状态处理函数推动，技师端通过 WebSocket 收到实时派单提醒。支付模块同时封装了微信支付 API v3、支付宝支付和余额支付，订单金额、分账比例等参数可直接在后台配置。另外，系统保留了城市代理相关模型和部分前端页面，虽然当前后台菜单标记为暂时下线，但路由和数据表都还在，适合后续恢复为多级区域分润模式。

数据库与数据设计

数据库采用 MySQL 8.4，全量表结构跟随源码一起交付。核心表包括用户、技师、服务项目、订单、支付流水、提现记录、分销关系等，表字段命名规范，索引设计对常见查询场景（按城市、按状态、按技师）做了覆盖。没有引入额外的缓存层，所有业务查询直连数据库。对于日均订单量在百级到千级的同城业务，这种设计足够稳定。如果后期需要承受更高并发，团队可以在 Gin 接口前挂接 Redis 做热点数据缓存，改动集中在 dao 层，不会污染业务逻辑。

部署方案

交付的源码中包含完整的 Docker Compose 编排文件，只需一台 2 核 4G 以上的 Linux 服务器，就能一键拉起所有服务。本地端口约定为：后端 8080，管理后台开发端口 5888，用户端 H5 端口 5173，MySQL 映射到主机 13308。生产环境可以将管理后台和用户端编译为静态文件，挂到 Nginx 下，再把后端 API 通过反向代理暴露。文件存储统一落在 uploads 目录，同样支持挂载云存储或 OSS，只需要替换 upload 驱动即可。

二次开发与接口扩展

整个系统的服务项目、价格规则、品牌名称、协议内容、页面装修全部在管理后台可视化完成，不用改一行代码就能从家政切换到保洁、维修、按摩、宠物护理等细分行业。如果要对接第三方，比如企业内部 CRM 或财务系统，后端接口全部遵照 RESTful 风格，返回格式统一，可以利用中间件快速增设新的路由组。技师端的排班模块、会员成长值规则、分销海报生成逻辑也都封装成独立 service，业务边界清晰，方便团队按接口文档替换或扩展。

团队接手与上线验收要点

源码交付的同时附带一份部署与接口说明文档，建议团队接手后先按以下 checklist 快速跑通流程：

• 使用 docker compose up 启动所有容器，确认各端口正常访问；
• 在后台配置微信支付商户号、支付宝应用密钥、腾讯地图 key 和短信通道，完成一笔完整的支付下单；
• 检查技师端实时接单推送是否依赖 WebSocket 长连接，压测 50 个并发订单无丢单；
• 验证不同城市定位下，服务列表和技师列表的筛选准确性；
• 按自身业务需求走通分销提现、预约排班、服务评价等完整链路。

代码采用标准的 Go module 管理依赖，前端 uni-app 工程可直接用 HBuilderX 打开，首次编译与运行时疑难点在 README 里都有标注。作为源码交付的项目，山东壹软网络科技有限公司提供了私有化部署和定制开发的技术支持，方便团队在商用授权内安心落地业务，避免踩坑。