最直接方案是用PHP session保存流程状态，但需解决过期、并发覆盖、多端同步等问题；推荐结合唯一flow_id存入数据库或Redis，并严格校验权限与原子性操作。
PHP 中用 session 保存流程状态最直接，但要注意过期和并发
用户中途退出、关浏览器后还想继续填表单或走审批流，核心是把当前步骤、已填数据、上下文变量存下来。PHP 默认的 session 是最快上手的方式，但它不是万能的——session 默认依赖 cookie，用户清了 cookie 就断；多个标签页同时操作同一流程，还可能互相覆盖 $_SESSION 里的键。
实操建议：
- 别直接往
$_SESSION['process']里塞大数组，先用json_encode()序列化，避免 session 写入失败或乱码 - 给每个流程实例生成唯一 ID（比如用
uniqid('flow_')），存在 session 里，再用这个 ID 当 key 存进 Redis 或数据库，这样即使 session 失效也能捞回来 - 如果流程跨天，别依赖默认 24 分钟的
session.gc_maxlifetime，要么调大，要么改用持久化存储
用数据库存流程快照比文件更可靠，尤其要支持多端同步
用户在手机填一半，回家用电脑接着填，这时候 session 完全失效。必须把断点数据落库，且带用户标识、流程类型、时间戳、状态字段（如 'status' => 'step2_pending'）。
常见错误现象：只存 user_id 和 data JSON 字段，结果无法区分“用户正在同时走两个报销流程”，导致数据错乱。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 表结构至少包含：
id（主键）、user_id、flow_type（如'onboarding'或'refund_apply'）、step_key（如'contact_info'）、data（TEXT 类型，存json_encode()后的字符串）、updated_at - 每次保存前先
SELECT ... FOR UPDATE锁住该用户的该流程记录，避免并发提交覆盖 - 不要在
data字段里存敏感信息（如身份证号、银行卡号），哪怕已加密——流程表权限容易被忽略，应单独脱敏处理
前端必须传 flow_id，否则后端根本不知道续哪个断点
很多实现卡在这一步：前端没把流程 ID 带过来，后端查不到上次存的状态，只能从头开始。这不是 PHP 的问题，是前后端约定缺失。
使用场景：表单分步组件、React/Vue 的多步骤 wizard、微信 H5 流程页。
实操建议：
- 第一步初始化时，后端返回一个
flow_id（从数据库插入后取lastInsertId()或用 UUID），前端必须存在 localStorage 或 URL query（如?flow_id=abc123）中，并在每步 POST 时带上 - 如果用户从分享链接进来（比如别人发的审批待办），URL 里已有
flow_id，前端要优先读它，而不是新建 - 别用
$_GET['flow_id']直接查库——必须校验该flow_id确实属于当前登录用户，防越权访问
Redis 做临时流程缓存时，key 设计和过期策略不能偷懒
高频流程（比如注册引导、活动抽奖路径）用 Redis 比 MySQL 更快，但很多人 key 写成 "flow:$user_id"，结果用户同时开两个流程就冲突。
性能影响：key 太宽泛会导致 GET/SET 误覆盖；过期时间设太长，垃圾数据堆积；设太短，用户慢一点操作就丢进度。
实操建议：
- key 格式用
"flow:$user_id:$flow_type:$timestamp"或直接用数据库生成的flow_id（如"flow:abc123"），确保唯一性 - 设置过期时间按流程预期时长 × 2，比如预计 10 分钟填完，设
EXPIRE flow:abc123 1200；但用户主动提交成功后，务必用DEL flow:abc123清掉 - 别把整个流程对象
serialize()存 Redis——PHP 反序列化有安全风险，一律用json_encode()/json_decode()
最易被忽略的是流程状态迁移的原子性：用户点“下一步”时，前端发请求，后端要先读旧状态、校验合法性、更新数据、再写新状态，这四步不能拆成多次 DB 查询。哪怕只是多一次 SELECT，在高并发下就可能续错断点。
