搞懂公司采购流程代码实现，面试必问不再慌
官方文档太长抓不住重点？别急，今天带你直击核心。很多后端面试必问“业务流如何代码化”，采购流程就是经典考题。
入口定位：从 HTTP 请求到 Service 层
在实际项目中，采购流程通常以 REST API 为入口。以 Java Spring Boot 为例，Controller 层负责接收请求并做初步校验。
@RestController
@RequestMapping(/api/procurement)
public class ProcurementController {@Autowiredprivate ProcurementService procurementService;// 创建采购申请@PostMapping(/apply)public ResponseEntityString createApply(@RequestBody ProcurementRequest request) {// 参数校验，防止非法数据进入核心逻辑if (request.getAmount() = 0) {return ResponseEntity.badRequest().body(Amount must be positive);}// 调用 Service 层处理业务逻辑String applyId = procurementService.createProcurement(request);return ResponseEntity.ok(Apply created with ID: + applyId);}
}这段代码看似简单，但藏着关键设计：职责分离。Controller 只关心“接什么、回什么”，不关心“怎么做”。面试时若被问“如何保证接口幂等性”，这里就是切入点——通过 applyId 做唯一约束，重复请求直接返回已存在记录，而非报错。
核心片段：状态机驱动的采购审批
采购流程的本质是状态流转：草稿 → 待审批 → 审批中 → 已通过/已驳回 → 已执行。官方文档常把这部分拆成十几个接口，初学者容易迷失。其实核心就一个类：状态机管理器。
@Service
public class ProcurementStateMachine {// 定义所有合法状态private static final MapString, SetString STATE_TRANSITIONS = Map.of(DRAFT, Set.of(PENDING_APPROVAL),PENDING_APPROVAL, Set.of(APPROVING, REJECTED),APPROVING, Set.of(APPROVED, REJECTED),APPROVED, Set.of(EXECUTED),REJECTED, Set.of() // 终态，不可再流转);// 状态流转核心方法public void transition(String currentStatus, String targetStatus, String applyId) {// 检查当前状态是否允许流转到目标状态SetString allowedTargets = STATE_TRANSITIONS.getOrDefault(currentStatus, Set.of());if (!allowedTargets.contains(targetStatus)) {throw new IllegalStateException(String.format(Cannot transition from %s to %s for apply %s, currentStatus, targetStatus, applyId));}// 这里应触发后续动作：如发送通知、记录审计日志、更新数据库log.info(Procurement {} transitioned from {} to {}, applyId, currentStatus, targetStatus);// 实际项目中，此处调用 repository.updateStatus(applyId, targetStatus)// 并发送领域事件，解耦后续通知、报表等逻辑}
}逐行解析：STATE_TRANSITIONS 用不可变 Map 定义状态图，避免运行时被篡改。这是参考了Spring Statemachine 开发者文档的最佳实践——状态转移规则应集中管理，而非散落在 if-else 中。
transition 方法不直接操作数据库，而是校验+触发事件。这符合事件驱动架构思想：状态变更是事实，通知、报表是副作用，二者解耦。
面试必问：“如何防止并发下状态错乱？”答案就在这一层——transition 方法需加分布式锁或乐观锁，确保同一时刻只有一个线程能改变某申请的狀態。设计思想：为什么不用 if-else 堆流程？
很多初学者会写成这样：
if (status == DRAFT) {// 转待审批
} else if (status == PENDING_APPROVAL) {// 转审批中
}问题在哪？扩展性差。新增一个“加急审批”状态，要改 N 处代码，极易漏改。而状态机把规则数据化，新增状态只需在 STATE_TRANSITIONS 加一行，transition 方法零改动。
更深的设计思想是领域模型驱动。采购流程不是一个“接口集合”，而是一个有生命周期的实体。每个状态对应明确的业务含义：DRAFT：申请人可修改、删除
PENDING_APPROVAL：只读，等待审批人认领
APPROVING：审批人可操作，其他角色只读
APPROVED：触发采购执行，财务可入账面试时若能说出“状态不是字符串，而是业务语义的载体”，立刻区别于背八股的候选人。
手写简化版：用 Python 实现最小可用状态机
为了加深理解，用 Python 写一个 50 行以内的简化版。重点不在功能完整，而在结构清晰。
from enum import Enum
from typing import Dict, Setclass ProcurementStatus(Enum):DRAFT = DRAFTPENDING_APPROVAL = PENDING_APPROVALAPPROVING = APPROVINGAPPROVED = APPROVEDREJECTED = REJECTEDEXECUTED = EXECUTEDclass ProcurementStateMachine:def __init__(self):# 状态转移表：当前状态 - 允许的目标状态集合self.transitions: Dict[ProcurementStatus, Set[ProcurementStatus]] = {ProcurementStatus.DRAFT: {ProcurementStatus.PENDING_APPROVAL},ProcurementStatus.PENDING_APPROVAL: {ProcurementStatus.APPROVING, ProcurementStatus.REJECTED},ProcurementStatus.APPROVING: {ProcurementStatus.APPROVED, ProcurementStatus.REJECTED},ProcurementStatus.APPROVED: {ProcurementStatus.EXECUTED},ProcurementStatus.REJECTED: set(), # 终态ProcurementStatus.EXECUTED: set(), # 终态}def can_transition(self, current: ProcurementStatus, target: ProcurementStatus) - bool:校验状态流转是否合法return target in self.transitions.get(current, set())def transition(self, current: ProcurementStatus, target: ProcurementStatus, apply_id: str) - None:执行状态流转，实际项目中此处持久化+发事件if not self.can_transition(current, target):raise ValueError(fIllegal transition: {current.value} - {target.value} for {apply_id})print(f[AUDIT] Apply {apply_id}: {current.value} - {target.value})# 模拟持久化# db.update(apply_id, status=target.value)# 模拟发送领域事件# event_bus.publish(ProcurementStatusChangedEvent(apply_id, current, target))关键细节：用 Enum 替代字符串，编译期/类型检查阶段就能拦截非法状态，比字符串安全得多。
can_transition 独立成方法，便于单元测试。面试常考“如何测试状态机？”——直接测这个方法，覆盖所有合法/非法转移组合。
transition 中的注释标明“实际项目中”该做什么。这提醒我们：核心逻辑要轻，副作用要解耦。应用场景：从采购流程看通用业务建模
采购流程只是表象，其底层模式适用于所有多角色、多阶段、有审批的业务：合同签署流程
发票报销流程
请假审批流程
订单履约流程共性是什么？状态 + 角色 + 动作 + 规则。抽象出这四个要素，就能快速搭建任何审批类业务。
面试实战中，若被问“如何设计一个通用的审批引擎”，不要急着写代码。先问清楚：状态有哪些？是否支持并行分支？
角色权限如何映射到状态操作？
是否需要超时自动流转？
审计日志粒度要求？然后给出分层方案：状态机管流转，权限拦截器管访问，事件总线管副作用，审计中间件管留痕。这种先澄清再设计的思路，比直接甩代码更显专业。政策变化与合格标准提示：
2024 年起，部分行业对采购流程的合规性要求提高，特别是涉及政府采购或上市公司采购，审计日志需保留 5 年以上，且状态变更必须可追溯到人。开发时若忽略审计字段（如 operator_id、timestamp、reason），上线后返工成本极高。
从培训学员角度看，合格标准不是“能跑通”，而是：状态转移规则集中管理，无散落的 if-else
每个状态变更有审计记录
并发场景下状态一致性有保证（锁或乐观锁）
单元测试覆盖所有合法/非法转移路径通过率方面，能独立画出状态图并说明设计取舍的学员，面试通过率明显高于仅能背诵“状态机是什么”的学员。建议动手用上述 Python 或 Java 代码跑一遍，故意制造非法转移，观察异常抛出行为，比看十遍文档更有记忆点。
你在项目里踩过这个坑吗？比如状态漏改导致数据不一致，或者并发下出现“双重审批”？评论区聊聊，互相避坑。
