7.2 KiB
tags, create time
| tags | create time | ||||
|---|---|---|---|---|---|
|
2026-08-09 12:00 |
有限状态机在业务中的应用 — 测试题
概述
本测试覆盖 FSM 的三种典型业务场景：审批流、订单生命周期和资源交付八阶段，以及非法转移防护和并发安全要求。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
一、选择题（6道，由浅入深）
难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
Q1（基础）— 考察定义层面
以下哪条订单状态转换是非法的？
A. PendingPayment → Paid（用户支付） B. Paid → Cancelled（已支付的订单直接取消） C. Shipped → Completed（用户确认收货） D. Refunding → Refunded（退款完成）
Q2（基础）→
审批流中"驳回"的语义可以是：
A. 只有一种——终止流程回到终态 B. 只有一种——退回上一步到前置状态 C. 两种都有可能——终止或退回，需要在模型中明确区分 D. 不是有效的状态转换事件
Q3（进阶）— 核心原理
资源交付八阶段中，为什么删除必须是两阶段的？
A. 因为存储 API 不支持一次性删除 B. 先标记 CleanupPending 再执行物理删除，避免误删且支持回滚 C. 因为需要等待 CDN 节点同步 D. 因为需要先通知用户
Q4（进阶）— 比较/辨析
以下关于三种业务场景 FSM 的对比描述哪个是正确的？
A. 审批流的循环转移最多（有退回修改） B. 订单生命周期的并发安全要求最低（单人审批） C. 资源交付是线性流程无循环转移 D. 三种场景的状态数量都在 5~8 之间
Q5（深入）— 场景推理
某电商平台的订单出现了一个状态转换请求：Paid → Cancelled（已支付后申请取消）。但系统校验发现这个转移是非法的。最合理的处理方式是：
A. 静默忽略，不报错也不执行 B. 返回错误 "invalid transition: PAID -> [CANCELLED]" C. 自动将订单转为 Shipping 状态 D. 将该请求丢入后台慢慢处理
Q6（深入）— 源码级/边界场景
原文提到审批链动态变化（A 请假了由 B 代审）时不应使用什么方案？
A. FSM 框架 B. 策略模式 + 规则引擎 C. 硬编码审批人 D. 数据库持久化
二、填空题（3道）
F1 — 填空1
审批流审计追踪中每次状态转换必须记录三个关键字段：_____、timestamp、comment。这些信息不可删除，用于事后合规审查。
提示: 回想原文表格中的字段名。
F2 — 填空2
资源交付场景中，"流量统计"被建模为_____而不是事件，因为流量统计是一个持续监控行为而非瞬时动作。在实际工程中它可能通过 sidecar 或事件总线持续运行，不受单用户的控制流影响。
提示: 回忆 FSM 的四个核心概念中哪个对应这个描述。
F3 — 填空3
订单生命周期并发安全要求_____，因为多人同时操作同一订单的场景频繁发生。解决方案是每步写 DB + 事件日志，必要时加乐观锁或悲观锁。
提示: 原文中的形容词，表示一种程度级别。
三、简答题（1道）
S1
面试官问："在一个在线学习平台中，一个课程工单从创建到完成会经历多个阶段：CREATED → ENROLLED → IN_PROGRESS → COMPLETED / DROPPED / REFUNDED。其中 REFUNDING 子流程包含 REFUND_REVIEW → REFUND_SUCCESS / REFUND_REJECT。如果 REFUND_REJECT 则回退到 IN_PROGRESS。请设计一个 FSM 状态图，并回答以下问题：
- 哪些转换是非法的？
- 如何防止用户在退款审核中途重复提交退款申请？
- 如何处理退款失败后的状态恢复？"
答题框架提示:
- 画出完整状态转换图（用文字描述节点和边）
- 分析非法转换场景
- 讨论幂等保护机制
- 异常路径的设计
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| Q1 | B | 原文列出的非法转移示例：Paid → Cancelled（已支付的订单不能直接取消），应该走 Refunding → Refunded 路径。Completed → Shipped 和 PendingPayment → Shipped 也是非法的。 |
| Q2 | C | 原文明确指出："驳回"可以是终止（回终态 Rejected）也可以是退回上一步（回到前置状态 ManagerRevise → Draft）。需要在模型中明确区分，不能混为一谈。 |
| Q3 | B | 原文警告：资源删除必须是两阶段的——先标记 CleanupPending 再执行物理删除。跳过这个阶段是数据丢失的头号原因。这提供了误删回滚的安全网。 |
| Q4 | C | A 错：订单生命周期也有循环（Refunding → Paid 退款拒绝→重新支付）；B 错：订单并发安全要求极高；D 错：资源交付是 8 个状态不在 5~8 的下限范围内。只有 C 正确——资源交付是线性流程无循环。 |
| Q5 | B | 非法转移应返回明确的错误信息而非静默忽略。原文明确说："非法转移应返回错误或被拒绝，而非静默忽略"。这样调用方能知道哪里出了问题。 |
| Q6 | C | 原文指出：审批链动态变化时硬编码审批人在生产环境中是不可接受的。应引入策略模式 + 规则引擎，让审批人分配变成可配置的。 |
填空题答案
| 题号 | 答案 | 解析 |
|---|---|---|
| F1 | operator |
审批流审计追踪的三个核心字段：operator（谁操作的）、timestamp（何时操作）、comment（什么理由）。这些数据不可删除以保障合规性。 |
| F2 | 状态 |
原文原话："流量统计是一个持续的监控行为，不是一个瞬时动作。FSM 在这里只记录'是否已进入此阶段'"。它是一个持续的行为标记。 |
| F3 | 极高 |
订单场景多人同时操作（如用户支付、客服退款、仓库发货可能在极短时间内相继发生），必须有强并发保护（乐观锁、事务、事件日志）。 |
简答题参考答案
S1：参考答案要点：
- 完整状态转换图：CREATED(初始) → ENROLLED(报名) → IN_PROGRESS(进行中)。IN_PROGRESS → COMPLETED(完成) / DROPPED(退出) / REFUNDING(申请退款)。REFUNDING → REFUND_REVIEW(审核中) → REFUND_SUCCESS(成功) → IN_PROGRESS(恢复) / REFUND_REJECT(拒绝) → IN_PROGRESS(继续学习)。
- 非法转换：CREATED → COMPLETED（未报名就完成）；ENROLLED → DROPPED（需要先开始才允许退出）；COMPLETED → IN_PROGRESS（已完成不能倒回去继续学）；IN_PROGRESS → CREATED（只能前进不能后退到更早状态）。
- 防重复退款：在 REFUNDING 状态下设置屏蔽——只有在 IN_PROGRESS 才能发起退款。收到退款请求时检查当前状态，如果不是 IN_PROGRESS 直接拒绝。配合数据库唯一约束做最终兜底。
- 恢复设计：REFUND_REJECT 回到 IN_PROGRESS 是因为退款失败不代表要退出课程。但如果是 REFUND_SUCCESS 则直接进入已完成状态（因为已经退款，服务关系终结）。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。