makemd/docs/ARCHIVE/08_Analysis/05_Service_State_Mapping.md

服务-状态映射分析报告

1. 状态机覆盖分析

已定义的状态机（11种）

1. Merchant（商户）状态：pending → active → inactive → suspended
2. User（用户）状态：pending → active → inactive → locked
3. Store（店铺）状态：pending → active → inactive → suspended
4. Feature（功能）状态：inactive → pending_payment → active → expired → suspended
5. Order（订单）状态：pending → paid → split → processing → shipped → completed → refunded → cancelled
6. Cross-Border E-Commerce（跨境电商）状态：PENDING → PROCESSING → CLEARANCE → SHIPPING → DELIVERED
7. SubOrder（子订单）状态：pending → processing → shipped → completed → refunded → cancelled
8. Product（商品）状态：draft → pending_approval → active → inactive → discontinued
9. Inventory（库存）状态：normal → low → out_of_stock → overstock
10. Payment（支付）状态：created → processing → paid → failed → refunded
11. Bill（账单）状态：pending → confirmed → settled → disputed
12. Settlement（结算）状态：pending → processing → completed → failed
13. Task（任务）状态：pending → running → success → failed → cancelled

业务流程状态需求

1. 数据采集与清洗闭环

• 状态需求：RAW_DATA → CLEANED → ANALYZED → READY_FOR_LISTING
• 覆盖情况：未覆盖
• 问题：缺少数据采集与清洗的状态定义

2. 商品刊登闭环

• 状态需求：READY_FOR_LISTING → LISTING_IN_PROGRESS → LISTED → MONITORING → NEED_UPDATE → UPDATED
• 覆盖情况：部分覆盖（Product状态机）
• 问题：缺少LISTING_IN_PROGRESS、MONITORING、NEED_UPDATE状态

3. 素材管理闭环

• 状态需求：UPLOADED → PROCESSING → PENDING_REVIEW → APPROVED → IN_USE → ARCHIVED/REJECTED
• 覆盖情况：未覆盖
• 问题：缺少素材管理的状态定义

4. 订单履约闭环

• 状态需求：PULLED → PENDING_REVIEW → CONFIRMED → ALLOCATED → READY_TO_SHIP → SHIPPED → DELIVERED → CLOSED
• 覆盖情况：部分覆盖（Order状态机）
• 问题：缺少PULLED、PENDING_REVIEW、ALLOCATED、READY_TO_SHIP、CLOSED状态

5. 售后逆向闭环

• 状态需求：REQUESTED → PROCESSING → APPROVED → REFUNDED → COMPLETED
• 覆盖情况：未覆盖
• 问题：缺少售后处理的状态定义

6. 报表与分析闭环

• 状态需求：RAW_DATA → PROCESSED → GENERATED → DISTRIBUTED → FEEDBACK_APPLIED
• 覆盖情况：未覆盖
• 问题：缺少报表处理的状态定义

2. 状态流转一致性分析

状态变更原则

• ✅ 所有状态变更必须通过Service
• ✅ 禁止前端直接控制状态
• ✅ 状态变更必须记录操作日志
• ✅ 状态变更必须遵循预定义的流转路径
• ✅ 状态变更可能触发相关业务逻辑

状态触发条件

• ✅ 商户状态：审核结果、逾期未付费、违规行为
• ✅ 用户状态：登录异常、权限变更、账号管理
• ✅ 店铺状态：平台审核、违规行为、商户操作
• ✅ 功能状态：支付结果、订阅到期、手动操作
• ✅ 订单状态：支付结果、商户操作、物流状态
• ✅ 商品状态：审核结果、库存状态、商户操作
• ✅ 库存状态：库存数量变化、库存同步
• ✅ 支付状态：支付渠道反馈、人工处理
• ✅ 账单状态：系统确认、支付结果、人工处理
• ✅ 结算状态：系统处理、支付结果、人工处理
• ✅ 任务状态：任务触发、执行结果、人工取消

3. 服务-状态映射分析

核心服务的状态使用

服务流程	使用的状态机	状态流转是否完整	问题
功能开通闭环	Feature状态	完整	-
跨境电商闭环	Cross-Border E-Commerce状态	完整	-
多商户订单闭环	Order状态	部分完整	缺少订单拆分状态
订单履约闭环	Order状态	部分完整	缺少履约中间状态
结算闭环	Settlement状态	完整	-
权限校验闭环	User状态	完整	-
商户管理闭环	Merchant状态	完整	-
店铺管理闭环	Store状态	完整	-
自动选品闭环	Task状态	完整	-
自动上架闭环	Task状态	完整	-
AI决策日志闭环	Task状态	完整	-
多租户数据隔离闭环	-	未覆盖	缺少租户状态

4. 状态管理问题

1. 状态定义不完整：大量业务流程缺少对应的状态定义
2. 状态流转不明确：部分业务流程的状态流转路径未明确定义
3. 状态触发条件缺失：部分状态变更的触发条件未明确
4. 状态与服务分离：部分服务操作没有明确的状态更新逻辑

5. 改进建议

短期改进（1-2个月）

1. 补全核心状态机：优先实现数据采集、素材管理、售后处理等核心业务流程的状态定义
2. 明确状态流转：为每个业务流程定义完整的状态流转路径
3. 关联状态与服务：确保每个服务操作都有明确的状态更新逻辑

中期改进（3-6个月）

1. 状态机可视化：建立状态机可视化工具，便于理解和管理状态流转
2. 状态监控：实现状态变更监控，及时发现和解决状态异常
3. 状态审计：建立状态变更审计机制，确保状态变更的可追溯性

长期改进（6个月以上）

1. 状态驱动设计：采用状态驱动的设计方法，将状态作为业务逻辑的核心
2. 状态机优化：持续优化状态机设计，提高系统的可维护性和可扩展性
3. 状态预测：利用AI技术预测状态变更，提前做好业务准备

6. 结论

当前系统已经定义了13种核心实体的状态机，覆盖了部分业务流程的状态需求，但仍有大量业务流程缺少对应的状态定义。建议按照优先级逐步补全缺失的状态定义，明确状态流转路径，关联状态与服务操作，确保业务流程的状态管理完整和一致。