背景与挑战
工厂里一台西门子 PLC 或 ABB 变频器罢工，停机一小时就是几万块的损失。但真要找人来修，客户面对的是一片混乱：找不到靠谱的工控技师、报价不透明、上门一趟没人知道修到哪一步、修完钱怎么分全靠口头约定。技师那头同样被动——接单靠关系、收入被层层抽成、干完活收不到钱。
通用上门服务平台（家政、家电维修）解不了这个问题：它们不懂工控，没有品牌/型号字典，也匹配不到具备 PLC、伺服、DCS 技能的技师。这是一个需要垂直行业知识 + 可信交易闭环的场景。
技术方案
三仓库微服务架构，各端职责清晰：
- gongkong-biz：Java 17 + Spring Boot 3 + MyBatis-Plus + Flyway 后端，单体同时服务 app 与 admin 双端
- gongkong-app：Expo / React Native for Web 移动端，一套代码覆盖客户 + 技师双角色，38 屏
- gongkong-admin：Next.js 16 + shadcn/ui + Tailwind v4 的 PC 管理后台
业务流程由订单状态机驱动：3 种订单类型（维修 REPAIR / 安装 INSTALL / 询价 KIT）、11 个状态、11 个事件。每一次状态流转都自动记录时间线——客户在 app 里、admin 在后台里，都能看到这张订单从下单到验收的完整轨迹。
关键设计：撮合 + 分账 + 审计的闭环
把"撮合交易"做扎实不难，难的是把钱和责任也管起来。这个平台的三件套是它的核心差异化：
1. 自动分账。 客户分两笔付（下单时的上门费/检测费 + 确认报价时的报价款），分账基数 = 上门费 + 报价款。平台抽成按订单类型可配置（默认维修 10%、安装 8%、询价 12%），订单验收完成自动生成分账记录，admin 一键结算。技师端「我的收益」显示的是已扣抽成的实际所得，待结算/已结算一目了然——收入透明，不靠口头对账。
按类型比例自动拆分，平台抽成 vs 技师所得，admin 一键结算
2. 全量操作审计。 一个通用 AOP 切面，自动记录 admin 端所有写操作（18 个端点）——登录、订单流转、技师审批、客户启停、分账结算、配置修改，全量留痕：操作人、动作、目标、时间、IP、参数详情。出问题可回溯，企业级合规。
操作人、动作、目标、时间、IP——admin 端写操作全量留痕
3. 照片/视频取证。 下单时的故障照片/视频、技师检测照片、安装现场照、签到照——全链路图片化，减少"修没修好"的扯皮。
一张订单的全部信息分区呈现：设备、故障、检测、时间线；材料明细属询价单，分账在独立页
产品化：双角色移动端 + PC 后台
移动端一套代码双角色：企业客户（15 屏）能维修/安装/询价三种下单、选 15 个工控品牌、传故障照片、跟踪订单、确认报价、验收评价；技师（14 屏）有抢单大厅、上门检测报价、现场签到拍照、收益管理。技师注册需 admin 审批（核验身份证、技能标签、从业年限、资质照片）。
移动端客户首页——公告、工控服务快捷入口、订单概览
PC 后台 11 个功能页：数据看板、订单管理、顾客/技师管理、分类树、评价管理，加上分账管理、分账配置、操作日志这三个差异化模块。
预置 15 个工控品牌字典（西门子、三菱、ABB、施耐德、松下、安川、汇川、欧姆龙、台达、富士、罗克韦尔、倍福、和利时、南瑞、其他），客户下单直接选品牌，技师按擅长领域精准匹配——这是通用平台做不到的垂直沉淀。
15 个工控品牌字典 + 故障照片/视频上传，垂直行业沉淀
技术栈
Spring Boot 3 / Java 17 / MyBatis-Plus / Flyway（V1–V20 共 20 个迁移）· 订单状态机（11 状态/3 类型/11 事件）· AOP 审计日志切面 · 服务端分账（幂等、按类型比例）· JWT 双端认证 · Expo / React Native for Web（一套代码双角色 38 屏）· Next.js 16 + shadcn/ui + Tailwind v4 · Docker Compose 单机部署 + nginx 统一入口 · 99 项后端集成测试 + 47 项 admin Playwright E2E
适用场景
- 工控设备维修/安装/询价的线上撮合（PLC、变频器、伺服、DCS）
- 任何需要"撮合 + 分账 + 审计"闭环的垂直 B2B 服务交易平台
- 多角色（客户/技师/平台运营）+ 三端（移动/PC/后端）的全栈产品原型