前阵子拆了同一家公司的 PDA 扫码需求最近又刷到他们一个单Java 微信小程序18-30K/月50 页5 端。50 页5 端这得多大仔细拆了一遍才发现拆开之后每一块都不复杂但拼在一起就是一套完整的本地生活 O2O 平台。这篇先把业务和架构理清楚。这个产品到底在做什么九个模块一句话概括用户下单找师傅上门服务门店和平台两边管理。把九个模块按角色分立刻清晰角色做什么对应模块 用户浏览服务 → 下单 → 支付 → 看进度商品管理、浏览下单 师傅接单/拒单 → 上门 → 完工拍照师傅模块 门店管服务项目、管手下师傅、看营收门店模块 配送取货/送货如果有实物商品配送模块️ 平台审核、退款、数据、推送管理后台、通知、裂变五个端就是五种入口用户小程序、师傅小程序、门店后台可能是小程序或 H5、配送端、平台 Web 管理后台。为什么是 50 页50 页听起来吓人但拆到每个端就合理了用户小程序~12 页首页LBS 附近门店/服务分类 ├── 服务详情 → 选择规格 → 下单页 ├── 门店详情 → 门店服务列表 └── 搜索 → 结果列表 订单tab ├── 全部/待服务/进行中/已完成 └── 订单详情进度、师傅信息、联系师傅 我的tab ├── 个人资料 ├── 我的地址 ├── 优惠券 └── 邀请有奖师傅小程序~8 页抢单大厅 → 订单列表 ├── 待接单 → 确认接单 ├── 进行中 → 导航到用户地址 → 完工上传照片 ├── 已完成 └── 已取消 我的 ├── 认证资料 ├── 收益明细 → 提现 └── 评价管理门店端~8 页工作台今日订单数/营收/在线师傅 ├── 服务管理上架/下架/改价 ├── 订单管理分配师傅/退款处理 ├── 师傅管理审核/排班/结算 └── 门店信息配送端~6 页待取件 → 已取件 → 配送中 → 已送达 ├── 取件扫码 ├── 导航到目的地 └── 签收确认平台管理后台 Web~16 页数据看板 ├── 用户管理列表/详情/封禁 ├── 师傅管理审核/资质/评分 ├── 门店管理入驻审核/合同/结算 ├── 订单管理全部订单/退款审核/纠纷处理 ├── 服务类目管理 ├── 优惠券/活动管理 ├── 财务结算 └── 系统配置抽佣比例/通知模板50 页就是这样堆出来的——每一页功能单一但角色多、端多总量就上去了。架构怎么设计五端 一套后端。不能塞在一个服务里——用户端和师傅端是高频操作管理后台是低频操作但查询复杂。至少拆三层┌─────────────────────────────────────────────┐ │ 客户端层 │ │ 用户小程序 │ 师傅小程序 │ 门店端 │ 配送端 │ │ (uni-app) │ (uni-app) │ (uni-app/H5) │ └──────────────┬──────────────────────────────┘ │ HTTPS JWT ┌──────────────▼──────────────────────────────┐ │ API 网关层 (Nginx) │ │ 路由分发 │ 限流 │ 日志 │ └──────┬──────────────┬───────────────┬───────┘ │ │ │ ┌──────▼──────┐ ┌─────▼──────┐ ┌─────▼──────────┐ │ 用户服务 │ │ 订单服务 │ │ 管理后台服务 │ │ - 登录注册 │ │ - 下单 │ │ - 审核 │ │ - 个人信息 │ │ - 接单/派单 │ │ - 退款 │ │ - 地址管理 │ │ - 状态流转 │ │ - 数据看板 │ │ - 优惠券 │ │ - 支付回调 │ │ - 结算 │ └──────┬──────┘ └─────┬──────┘ └─────┬──────────┘ │ │ │ └──────────────┼───────────────┘ │ ┌─────────────────────▼────────────────────────┐ │ 基础设施层 │ │ MySQL │ Redis │ 对象存储 │ 微信支付 │ 地图API │ └──────────────────────────────────────────────┘为什么拆三个服务用户服务和订单服务分开订单挂了不影响登录登录挂了用户还能看到缓存里的历史订单管理后台独立后台的复杂连表查询不会拖慢用户端但你只有一台 2C4G 服务器所以不是物理拆三台是逻辑拆三个模块一个 JAR 里三个包——将来量大了再拆技术选型层选型为什么用户端 师傅端 门店端uni-appVue 3一套代码三端出你熟。微信原生也可以但 50 页跨端维护成本太高后端Spring Boot 3 MyBatis-Plus你现有技术栈零学习成本数据库MySQL订单/用户/门店都是关系型数据缓存Redis门店列表、首页服务分类、师傅位置——高频读、低频写支付微信支付 V3 API下单支付 分账给师傅/门店结算地图腾讯地图 API小程序原生支持最好LBS 搜索免费额度够用消息推送微信模板消息 / 订阅消息订单状态变更通知用户和师傅图片存储阿里云 OSS 或本地磁盘师傅完工照、门店头图哪些是真正的难点50 页的 UI 不是难点——CRUD 堆页熟手三四天搬完。真正的难点在三个地方1. 订单状态机一个订单从创建到完结至少经历 8 种状态待支付 → 已支付 → 待接单 → 已接单 → 服务中 → 已完成 → 已评价 ↘ 已取消超时没人接 ↘ 已退款而且不同角色看到的下一步操作不同用户想取消、师傅想拒单、平台想退款——同一个状态三个入口三个逻辑。2. 师傅匹配和派单是师傅抢单谁手快谁接还是平台派单按距离/评分/接单量分配抢单简单但体验差师傅刷屏等单派单体验好但需要匹配算法。一个 18-30K 的项目大概率是抢单 门店手动分配的组合——70% 抢单30% 门店指派。3. 结算分账用户付 100 块 → 平台抽 10%10 块→ 门店抽 20%18 块→ 师傅拿 72 块。微信支付分账 API 能自动分但前提是各方都得入驻微信商户平台。小项目大概率走人工结算——平台定期导出账单转账打款。如果用文章来呈现这个项目比 PDA 更适合写文章。PDA 缺硬件只能推演O2O 是全软件——设计文档写出来读者可以直接拿去参考甚至复用。下一篇我会把数据库设计和核心接口设计完整展开用户-师傅-门店三套权限模型、订单表的状态机字段设计、下单到完工的完整 API 调用链。关于作者无羡独立开发者全栈工程师专注 AI 应用与微服务架构。 分类技术复盘 个人博客 — 更多技术文章✨ 开发者福利整理 — 云服务资源汇总 软件工坊 — 我的技术分享 个人门户 — 独立开发作品全集