核心是实现表单状态可流转、字段可校验、提交触发审批链路：字段名/格式需与后端状态机严格一致，审批人由后端返回并控制流程，校验分层处理，提交后通过轮询或消息模板同步状态。
uni-app 制作请假审批流程表单，核心不是“怎么画个表单”，而是「如何让表单状态可流转、字段可校验、提交后能触发审批链路」。直接套用 v-model 绑定 + uni-forms 组件只能完成静态录入，真正在企业微信或小程序里跑通审批，必须和后端状态机对齐字段、时机与错误反馈逻辑。
表单字段必须和后端状态机入参严格一致
很多开发者在 uni-app 里随手加 leaveType、startTime、endTime，但后端状态机（比如 Spring Boot 里的 LeaveStateMachine）实际接收的是 leave_type（下划线）、start_time、end_time，且要求 start_time 是 ISO 8601 格式字符串（如 "2026-10-30T09:00:00"），不是 Date 对象或时间戳。不一致会导致提交成功但审批节点卡死。
- 前端字段名要查后端接口文档或 DTO 类，比如
LeaveApplyDTO的字段命名和类型 -
uni-datetime-picker的value输出是时间戳，必须用new Date(ts).toISOString().slice(0, 19)转成后端可解析格式 - 请假类型下拉项的
value必须和后端枚举值完全一致（如后端是"annual_leave"，不能写成"年假"或"ANNUAL_LEAVE"） - 附件上传走的是单独接口（如
/api/attachment/upload），返回的fileId才是表单提交时要塞进attachments字段的数组项
审批人自动计算逻辑不能放在前端
常见错误是用 uni.getStorageSync('userInfo') 拿到当前用户部门 ID，再请求 /api/approver?deptId=xxx 查审批人，然后把结果塞进表单隐藏域提交——这等于把审批链路规则暴露给前端，任意用户都能伪造请求绕过直属上级。
- 审批人列表必须由后端在表单页初始化接口（如
GET /api/leave/form/init）中返回，且附带每个节点的nodeCode（如"direct_manager"） - 前端只负责渲染，不参与计算；提交时只传原始业务字段，由后端根据当前用户身份+组织架构+配置规则动态生成审批流
- 若需显示“下一步审批人是张经理”，应由后端在响应中返回
nextApproverName字段，而非前端拼接
表单校验要分层：UI 层 + 接口层 + 状态机层
uni-app 的 uni-forms 只能做基础非空、日期范围校验，但真实场景中很多规则是动态的：比如“事假超过3天需附说明”“病假必须上传诊断证明”“调休不可跨月”。这些规则必须由后端在 POST /api/leave/apply 接口内执行，前端只做兜底提示。
- 前端校验用
rules配置必填、日期早于今天、结束时间晚于开始时间等硬性条件 - 提交前调用
form.validate()，但不要拦截所有错误——比如后端返回{"code":400,"msg":"病假未上传诊断证明"}，应原样 toast 提示，而不是前端自己判断类型再弹窗 - 避免在
submit回调里写 if-else 判断请假类型再决定是否弹窗，规则应统一收口到后端 - 表单禁用状态要靠响应式数据控制，比如提交中设
isSubmitting = true，防止重复点击，但不要用disabled属性锁死整个 form（会影响 accessibility）
提交后跳转和状态同步容易被忽略
表单提交成功后，很多人直接 uni.navigateTo({ url: '/pages/status/detail?id=' + res.data.id })，但没处理「审批中」页面的实时状态更新。用户退出再进来，看到的还是“已提交”，而不是“王总监已通过”。
- 推荐方案：提交成功后跳转到带轮询的详情页，每 5 秒调用
GET /api/leave/status?id=xxx获取最新节点状态 - 轮询要加防抖，比如用户切后台时
clearInterval，切回前台再启动，避免白屏耗电 - 企业微信/微信小程序里，如果开通了消息模板，后端应在每个审批节点变更时调用
POST /api/wx/message/send，前端无需主动拉取 - 若使用 uni-app 的
onShow生命周期刷新状态，注意它在 tabbar 页面中不会触发，得用onTabItemTap或全局事件总线
