基于 Spring Boot + Vue 3 + uni-app 的灵活用工系统：四端架构与业务流程设计

企业发布一项服务任务后，如何把人员报名、任务确认、交付验收、报酬结算和凭证查询串起来？本文面向正在规划灵活用工平台的产品人员和全栈开发者，结合一个已有代码实现的项目，介绍四端分工、核心功能及关键设计。

系统后端基于 Java 17、Spring Boot 和 MyBatis，Web 端采用 Vue 3，移动端采用 uni-app。本文以当前项目源码为依据，重点说明业务如何衔接，以及开发时需要关注的数据一致性问题。

图 1：运营大屏汇总企业、人员、发包、订单及资金进度。

一、系统定位与四端分工

系统围绕企业、灵工和平台运营三类参与者，设置四个使用端。

使用端	面向人群	主要功能
平台管理端	运营、审核和财务人员	企业认证、人员审核、发包审核、结算财税、资金记录、工单与审计
企业 PC 端	企业管理、业务和财务人员	项目维护、任务发包、报名录用、交付验收、资金与发票查询
企业移动端	需要移动办公的企业成员	工作台、发包、报名处理、订单及验收查询
灵工移动端	承接服务任务的人员	实名资料、协议、找活报名、任务确认、交付及收入查询

例如，企业业务人员可以在 PC 端集中处理报名，也可以在手机上查看订单；灵工则通过移动端完成找活、报名和交付。各端围绕同一套业务记录协作。

企业成员还区分管理员、业务、财务和只读等角色。菜单与操作入口随角色调整，服务端同时校验对应权限。

图 2：平台工作台集中呈现待办、业务趋势和运营数据。

二、从发包到结算的业务流程

系统的主要业务关系如下：
#mermaid-svg-WiGLb3hM0U3Z6U9x{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-WiGLb3hM0U3Z6U9x .error-icon{fill:#552222;}#mermaid-svg-WiGLb3hM0U3Z6U9x .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-WiGLb3hM0U3Z6U9x .marker{fill:#333333;stroke:#333333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .marker.cross{stroke:#333333;}#mermaid-svg-WiGLb3hM0U3Z6U9x svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-WiGLb3hM0U3Z6U9x p{margin:0;}#mermaid-svg-WiGLb3hM0U3Z6U9x .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster-label text{fill:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster-label span{color:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster-label span p{background-color:transparent;}#mermaid-svg-WiGLb3hM0U3Z6U9x .label text,#mermaid-svg-WiGLb3hM0U3Z6U9x span{fill:#333;color:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .node rect,#mermaid-svg-WiGLb3hM0U3Z6U9x .node circle,#mermaid-svg-WiGLb3hM0U3Z6U9x .node ellipse,#mermaid-svg-WiGLb3hM0U3Z6U9x .node polygon,#mermaid-svg-WiGLb3hM0U3Z6U9x .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .rough-node .label text,#mermaid-svg-WiGLb3hM0U3Z6U9x .node .label text,#mermaid-svg-WiGLb3hM0U3Z6U9x .image-shape .label,#mermaid-svg-WiGLb3hM0U3Z6U9x .icon-shape .label{text-anchor:middle;}#mermaid-svg-WiGLb3hM0U3Z6U9x .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .rough-node .label,#mermaid-svg-WiGLb3hM0U3Z6U9x .node .label,#mermaid-svg-WiGLb3hM0U3Z6U9x .image-shape .label,#mermaid-svg-WiGLb3hM0U3Z6U9x .icon-shape .label{text-align:center;}#mermaid-svg-WiGLb3hM0U3Z6U9x .node.clickable{cursor:pointer;}#mermaid-svg-WiGLb3hM0U3Z6U9x .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .arrowheadPath{fill:#333333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-WiGLb3hM0U3Z6U9x .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-WiGLb3hM0U3Z6U9x .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-WiGLb3hM0U3Z6U9x .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster text{fill:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x .cluster span{color:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-WiGLb3hM0U3Z6U9x .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-WiGLb3hM0U3Z6U9x rect.text{fill:none;stroke-width:0;}#mermaid-svg-WiGLb3hM0U3Z6U9x .icon-shape,#mermaid-svg-WiGLb3hM0U3Z6U9x .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-WiGLb3hM0U3Z6U9x .icon-shape p,#mermaid-svg-WiGLb3hM0U3Z6U9x .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-WiGLb3hM0U3Z6U9x .icon-shape .label rect,#mermaid-svg-WiGLb3hM0U3Z6U9x .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-WiGLb3hM0U3Z6U9x .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-WiGLb3hM0U3Z6U9x .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-WiGLb3hM0U3Z6U9x :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 企业认证与平台协议
创建项目和服务任务
平台审核与预算冻结
灵工报名与企业录用
生成成本订单和任务确认书
灵工阅读确认
服务记录与交付
企业验收
生成结算并核税复核
结算审核与报酬支付
申报记录与完税凭证

这些环节通过项目、发包、报名、成本订单等业务编号关联。打开单笔订单，可以追溯任务确认书、交付验收、结算以及对应税务进度。

1. 项目管理与任务发包

企业先创建项目，再维护具体服务任务。发包信息包含服务内容、地点、服务期间、招募人数、计量单位、单价、计划数量、验收标准和结算周期等。

发包提交时保存当次内容快照，随后进入平台审核。审核通过后冻结相应预算，再开放报名。任务状态包含草稿、待审核、驳回、招募中、关闭和完成。

这样设计可以让审核记录对应明确的任务版本，也让后续订单获得可追溯的服务约定。

图 3：按企业和项目查看任务的审核状态、冻结预算及招聘进度。

2. 报名录用与任务确认

灵工在找活列表中筛选任务并提交报名，企业查看报名资料后决定是否录用。后端在录用时检查任务状态、截止日期、剩余名额，以及人员认证、框架协议和风险状态。

录用成功后，系统生成成本订单和《单次任务承揽确认书》，记录任务内容、服务期间、单价及计量上限。

当前业务模型中，单次任务确认书基于平台与灵工已签署的框架协议生成，企业作为任务来源记录。灵工阅读并确认后，订单进入履约阶段。文书保存生成时的正文与内容摘要，后续资料修改不会改写历史约定。

3. 服务交付与验收

履约过程中可以登记服务打卡、提交交付材料，并由企业进行验收。移动打卡使用设备定位能力，提交记录时同时校验订单归属和业务状态。

系统支持部分验收和全部验收。结算依据审核通过的交付结果生成，并记录已验收与已结算数量，避免同一部分交付被重复结算。

例如，某项按件计费的服务约定单价为 100 元，本次通过验收 8 件，则这部分服务的税前报酬为 800 元。个税、实发金额及平台服务费按各自业务规则处理，不应混用口径。

图 4：验收详情记录交付内容、申请金额、审核金额及完成凭证。

4. 结算、付款与税务记录

结算流程区分核税、核税复核、结算复核和实际付款，分别保存经办记录。税务模块包含申报批次、缴税回执、个人完税凭证及更正补退记录。

图 5：结算审核按核税、复核、发起支付等状态组织业务。

这里有一个需要明确的状态关系：报酬已支付、税款已缴纳和完税凭证已核验，是三个不同的业务结果。 企业和灵工查询订单时，可以看到各环节的实际进度。

对于线下办理的环节，系统通过实际回执和材料登记结果。税务规则的适用范围需要结合实际业务主体和运营条件确认。

图 6：出纳付款页面汇总待付款记录，并提供实际付款与回执登记入口。

三、技术架构与代码组织

层次	主要技术	职责
后端服务	Java 17、Spring Boot、Spring Security	接口、身份认证、权限和业务流程
持久化	MyBatis、MySQL	业务记录、状态、关联查询和事务
缓存	Redis	验证码及相关缓存、频控能力
管理端和企业 PC	Vue 3、TypeScript、Vite、Element Plus、Pinia	Web 业务操作和管理界面
企业与灵工移动端	uni-app、Vue、TypeScript	移动业务入口
共享前端	共享组件与业务定义	统一字段、状态、详情与交互逻辑

项目沿用已有管理框架，在原有工程中扩展灵活用工业务。主要目录如下：

text 复制代码

src/
├─ server/mage-admin/  后端业务接口与服务
├─ admin/             平台管理端
├─ company-pc/        企业 PC 端
├─ company-m/         企业移动端
├─ user-m/            灵工移动端
└─ shared/labor/      共享业务定义与组件

db/labor/             数据库增量迁移
tools/labor/          构建与维护工具

共享层集中维护状态名称、业务字段和通用详情组件。例如，结算单在企业 PC 和企业移动端采用一致的状态含义，降低多端分别维护造成的展示偏差。后端按管理、企业和灵工入口组织接口，并在服务层处理业务状态变化。

四、四个关键设计点

1. 企业与个人数据隔离

企业端查询受当前企业及成员权限约束，灵工端查询受当前登录人员约束。前端传入的查询条件只能缩小范围，不能扩大可访问的数据范围。

报名详情、订单详情和附件访问都需要独立校验归属。列表能够正确过滤，并不意味着详情接口可以省略权限检查。

2. 事务、版本检查与重复提交处理

录用涉及报名、招募名额、成本订单和确认书等多条记录，需要在同一事务内完成。关键写入结合行锁、版本检查及数据库约束处理状态竞争。

以下摘取录用逻辑中的关键判断，省略了其他业务校验和写入，仅用于说明处理顺序：

java 复制代码

var j = found(jobs.lock(initial.jobId));
var a = found(applications.lock(applicationId));
var prior = query.orderByApplication(applicationId);
if (prior != null) return prior;

version(a.version, expected);
require(j.hiredCount < j.headcount, "招募名额已满");

锁定任务和报名记录后，先检查是否已有订单，再校验版本与名额。用户因网络延迟再次点击录用时，已有订单可以被识别，避免重复生成业务结果。

3. 金额与收款信息快照

金额采用 BigDecimal 与数据库 DECIMAL 表达。预算冻结、结算和资金释放通过对应资金记录追溯。

结算还会固化当时认证通过的收款信息。人员之后修改银行卡资料，历史付款仍使用原单据中的收款快照，避免当前资料覆盖历史支付依据。

4. 私有材料与操作审计

身份证、银行卡和签署材料采用私有文件访问方式，普通业务列表使用脱敏信息。敏感资料的查看还受角色、单据状态和业务归属约束。

审核、录用、付款和退款等关键操作保留审计记录。排查一笔业务时，可以沿着关联单据核对操作人、处理结果及材料。

五、第三方服务的接入边界

介绍系统时，需要区分业务功能、接口适配和真实渠道联调。按当前实现，主要能力如下：

能力	当前实现情况
短信	已有阿里云短信渠道实现，是否真实发送取决于有效配置与启用状态
文件存储	支持本地及阿里云 OSS 存储，并记录材料实际存储方式
电子签约	已有线下材料流程和 e签宝适配基础，真实渠道仍待厂商联调验证
身份核验	已有人工审核及阿里云 OCR、身份核验适配基础，真实调用默认关闭
报酬付款	支持付款审核及实际银行回执登记，银行自动代付仍需渠道接入
电子发票	已有申请、票据及红冲记录，并预留渠道接入基础
税务申报	已有核算、批次、回执及凭证管理，自动申报渠道仍待接入

保存了服务商参数，或本地配置检查通过，都不能替代真实接口联调。系统应根据实际办理结果展示状态，让使用者知道当前环节如何完成。

六、适用场景与后续扩展

这套系统适合需要统一管理服务任务、外部人员协作、交付验收和报酬结算的业务场景。例如，项目制服务可以按任务约定计量方式，再按验收结果进入结算。

后续扩展可以围绕银行代付、电子签约、身份核验和票税渠道逐项开展，并结合多端实机验证、并发测试及备份恢复验证完善交付。

对类似项目而言，可以先把一笔业务从发包到凭证查询完整走通，再扩展批量处理和自动渠道。四端界面、服务端权限和业务单据使用同一套状态规则，才能让每个参与者理解当前进度，并找到下一步操作。