vault backup: 2026-08-09 19:06:40

2026-08-09 19:06:40 +08:00
parent e2975eb86b
commit 9d664545c9
46 changed files with 7287 additions and 0 deletions
@@ -0,0 +1,144 @@
+---
+tags: [test/review, fsm, pattern, workflow-engine]
+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 状态图，并回答以下问题：
+1. 哪些转换是非法的？
+2. 如何防止用户在退款审核中途重复提交退款申请？
+3. 如何处理退款失败后的状态恢复？"
+
+> **答题框架提示**:
+> 1. 画出完整状态转换图（用文字描述节点和边）
+> 2. 分析非法转换场景
+> 3. 讨论幂等保护机制
+> 4. 异常路径的设计
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| 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：**参考答案要点**：
+1. **完整状态转换图**：CREATED(初始) → ENROLLED(报名) → IN_PROGRESS(进行中)。IN_PROGRESS → COMPLETED(完成) / DROPPED(退出) / REFUNDING(申请退款)。REFUNDING → REFUND_REVIEW(审核中) → REFUND_SUCCESS(成功) → IN_PROGRESS(恢复) / REFUND_REJECT(拒绝) → IN_PROGRESS(继续学习)。
+2. **非法转换**：CREATED → COMPLETED（未报名就完成）；ENROLLED → DROPPED（需要先开始才允许退出）；COMPLETED → IN_PROGRESS（已完成不能倒回去继续学）；IN_PROGRESS → CREATED（只能前进不能后退到更早状态）。
+3. **防重复退款**：在 REFUNDING 状态下设置屏蔽——只有在 IN_PROGRESS 才能发起退款。收到退款请求时检查当前状态，如果不是 IN_PROGRESS 直接拒绝。配合数据库唯一约束做最终兜底。
+4. **恢复设计**：REFUND_REJECT 回到 IN_PROGRESS 是因为退款失败不代表要退出课程。但如果是 REFUND_SUCCESS 则直接进入已完成状态（因为已经退款，服务关系终结）。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[有限状态机核心概念]]