wurenzhi/makemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 添加货币和汇率管理功能

Browse Source 
refactor: 重构前端路由和登录逻辑

docs: 更新业务闭环、任务和架构文档

style: 调整代码格式和文件结构

chore: 更新依赖项和配置文件
This commit is contained in:
wurenzhi
2026-03-19 19:08:15 +08:00
parent 8de9ea0aaa
commit eafa1bbe94
203 changed files with 20240 additions and 39580 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/06_Reports/00_Reports_Index.md Normal file
View File

@@ -0,0 +1,28 @@
# 报告文档索引
> **模块**: 06_Reports - 项目报告与分析
> **更新日期**: 2026-03-19
---
## 报告列表
| 文档 | 描述 | 状态 |
|------|------|------|
| [01_Business_ClosedLoop](01_Business_ClosedLoop.md) | 业务闭环报告 | ✅ |
| [02_Code_Review](02_Code_Review.md) | 代码审查报告 | ✅ |
| [03_Development_Progress](03_Development_Progress.md) | 开发进度报告 | ✅ |
| [04_Temporary](04_Temporary.md) | 临时建议与修改 | ✅ |
---
## 关联模块
- [业务模块](../00_Business/Business_Blueprint.md)
- [分析模块](../08_Analysis/00_Analysis_Index.md)
---
## 最近更新
- 2026-03-19: 创建报告模块，归档历史报告

150
docs/06_Reports/01_Business_ClosedLoop.md Normal file
View File

@@ -0,0 +1,150 @@
# 业务到功能闭环完整性报告
## 1. 总体评估
### 闭环完整性评分
| 维度 | 评分 | 状态 | 主要问题 |
|------|------|------|----------|
| 业务-服务映射 | 40% | 部分覆盖 | 大量业务闭环缺少对应服务实现 |
| 服务-状态映射 | 50% | 部分覆盖 | 状态定义不完整，状态流转不明确 |
| 前端-业务映射 | 45% | 部分覆盖 | 前端页面覆盖不完整，功能深度不足 |
| 数据闭环 | 60% | 基本完整 | 存在数据断点和一致性问题 |
| 异常处理 | 55% | 部分覆盖 | 异常处理机制不完整，通知不及时 |
| **总体评分** | **50%** | **部分覆盖** | **核心业务闭环基本覆盖，边缘业务闭环覆盖不足** |
## 2. 主要发现
### 2.1 业务-服务映射问题
- **服务覆盖不足**：69个业务闭环中，仅24个有对应的服务实现，覆盖率仅35%
- **核心服务缺失**：营销、供应链、物流、财务等核心业务领域缺少服务实现
- **服务调用链不完整**：部分服务调用链直接从Controller到Repository，缺少Service层业务逻辑
### 2.2 服务-状态映射问题
- **状态定义不完整**：大量业务流程缺少对应的状态定义
- **状态流转不明确**：部分业务流程的状态流转路径未明确定义
- **状态与服务分离**：部分服务操作没有明确的状态更新逻辑
### 2.3 前端-业务映射问题
- **页面覆盖不完整**：大量业务闭环缺少对应的前端页面
- **功能深度不足**：部分页面只覆盖了基础功能，缺少高级功能
- **用户体验不一致**：不同模块的用户体验设计不一致
### 2.4 数据闭环问题
- **数据断点**：部分业务流程中存在数据流转断点
- **数据一致性**：不同系统间的数据一致性问题
- **数据质量**：数据采集和处理过程中的数据质量问题
### 2.5 异常处理问题
- **异常处理不完整**：部分异常类型缺少专门的处理机制
- **异常通知不及时**：部分异常没有及时的通知机制
- **异常记录不完整**：部分异常没有完整的记录
## 3. 优先级问题列表
### P0 - 紧急问题
1. **核心服务缺失**：营销、供应链、物流、财务等核心业务领域缺少服务实现
2. **状态定义不完整**：商品刊登、订单履约等核心业务流程缺少状态定义
3. **前端页面缺失**：核心业务功能缺少对应的前端页面
### P1 - 高优先级问题
1. **服务调用链不完整**：部分服务调用链缺少Service层业务逻辑
2. **数据流转断点**：核心业务流程中存在数据流转断点
3. **异常处理机制不完整**：核心业务流程缺少异常处理机制
### P2 - 中优先级问题
1. **功能深度不足**：部分页面功能深度不足
2. **用户体验不一致**：不同模块的用户体验设计不一致
3. **数据质量问题**：数据采集和处理过程中的数据质量问题
### P3 - 低优先级问题
1. **边缘业务覆盖不足**：边缘业务闭环缺少服务和页面实现
2. **异常通知不及时**：部分异常没有及时的通知机制
3. **状态监控缺失**：缺少状态变更监控机制
## 4. 改进建议
### 4.1 短期改进（1-2个月）
#### 核心服务补全
- **营销服务**：实现广告管理、ROI分析、营销策略服务
- **供应链服务**：实现供应商管理、采购管理、补货建议服务
- **物流服务**：实现物流策略、渠道选择、运费计算服务
- **财务服务**：实现资金对账、回款管理、利润核算服务
#### 状态定义补全
- **商品状态**：完善商品刊登流程的状态定义
- **订单状态**：完善订单履约流程的状态定义
- **数据状态**：完善数据采集与清洗流程的状态定义
#### 前端页面补全
- **营销页面**：广告管理、ROI分析、营销策略配置页面
- **供应链页面**：供应商管理、采购管理、补货建议页面
- **物流页面**：物流策略、渠道选择、运费计算页面
- **财务页面**：资金对账、回款管理、利润核算页面
### 4.2 中期改进（3-6个月）
#### 服务架构优化
- **服务模块化**：将大型服务拆分为更小的、可复用的服务模块
- **服务编排**：实现服务编排机制，支持复杂业务流程的自动化执行
- **服务监控**：建立服务调用监控体系，及时发现和解决服务问题
#### 状态管理优化
- **状态机可视化**：建立状态机可视化工具，便于理解和管理状态流转
- **状态监控**：实现状态变更监控，及时发现和解决状态异常
- **状态审计**：建立状态变更审计机制，确保状态变更的可追溯性
#### 前端体验优化
- **响应式优化**：确保所有页面支持多端适配
- **性能优化**：优化前端性能，提升用户体验
- **组件库建设**：建立统一的组件库，提高开发效率
### 4.3 长期改进（6个月以上）
#### 架构升级
- **微前端架构**：采用微前端架构，支持大型模块独立部署
- **BFF层**：引入Backend for Frontend模式，统一接口管理
- **数据中台**：构建数据中台，实现数据的集中管理和共享
#### 智能能力
- **AI决策支持**：实现AI驱动的智能决策系统
- **智能异常处理**：利用AI技术实现智能异常处理
- **智能数据分析**：利用AI技术实现智能数据分析和预测
#### 生态建设
- **服务治理**：建立服务治理体系，确保服务质量和可靠性
- **开发者生态**：建立开发者生态，支持第三方集成
- **策略市场**：建立策略市场，支持用户共享和交易AI策略
## 5. 验收标准
### 5.1 业务-服务映射验收
- ✅ 所有核心业务闭环都有对应的服务实现
- ✅ 所有服务调用链完整，包含必要的Service层业务逻辑
- ✅ 服务调用链符合逻辑集中化原则
### 5.2 服务-状态映射验收
- ✅ 所有核心业务流程都有完整的状态定义
- ✅ 所有状态变更都通过Service层执行
- ✅ 所有状态流转路径明确且符合业务逻辑
### 5.3 前端-业务映射验收
- ✅ 所有核心业务功能都有对应的前端页面
- ✅ 前端页面功能完整，满足业务需求
- ✅ 前端页面用户体验一致，响应式支持良好
### 5.4 数据闭环验收
- ✅ 所有核心业务数据都有完整的生命周期
- ✅ 数据流转路径完整，无断点
- ✅ 数据一致性得到保证，数据质量良好
### 5.5 异常处理验收
- ✅ 所有异常类型都有专门的处理机制
- ✅ 异常通知及时，记录完整
- ✅ 异常处理机制可靠，系统稳定性良好
## 6. 结论
当前系统已经实现了核心业务闭环的基本功能，但仍有大量业务领域缺少完整的实现。建议按照优先级逐步补全缺失的服务、状态定义和前端页面，优化服务架构和状态管理，提升前端用户体验，确保业务到功能的完整闭环。
通过系统性的改进，可以提高系统的稳定性、可靠性和用户体验，为业务发展提供有力的技术支持。

509
docs/06_Reports/02_Code_Review.md Normal file
View File

@@ -0,0 +1,509 @@
# 代码审查报告
> **审查日期**: 2026-03-19
> **审查范围**: 全代码库深度检查
> **审查目标**: 逻辑统一性、冗余代码、潜在冲突
---
## 📊 审查概览
| 类别 | 问题数量 | 严重程度 | 状态 |
|------|----------|----------|------|
| 🔴 严重问题 | 3 | 高 | 需立即修复 |
| 🟡 中等问题 | 5 | 中 | 需计划修复 |
| 🟢 轻微问题 | 4 | 低 | 建议优化 |
---
## 🔴 严重问题
### 1. 服务层逻辑重复与不一致
**问题描述**:
`ArbitrageService` 和 `PriceComparisonService` 存在高度重复的逻辑，但实现细节不一致。
**涉及文件**:
- `server/src/services/ArbitrageService.ts`
- `server/src/services/PriceComparisonService.ts`
**具体问题**:
#### 1.1 汇率数据不一致
```typescript
// ArbitrageService.ts (第62行)
private static readonly EXCHANGE_RATE = 7.2; // 硬编码单一汇率
// PriceComparisonService.ts (第65-71行)
private static readonly EXCHANGE_RATES: Record<string, number> = {
'CNY-USD': 0.14,
'USD-CNY': 7.2,
'CNY-EUR': 0.13,
'EUR-CNY': 7.7,
'USD-EUR': 0.92,
'EUR-USD': 1.09
};
```
**影响**: 两个服务对相同货币对可能计算出不同的汇率结果。
#### 1.2 机会评分算法不一致
```typescript
// ArbitrageService.ts (第465-470行)
private calculateOpportunityScore(profitSnapshot: ProfitSnapshot): number {
const profitRateScore = Math.min(profitSnapshot.profitRate * 200, 40);
const roiScore = Math.min(profitSnapshot.roi * 50, 30);
const netProfitScore = Math.min(profitSnapshot.netProfit / 10, 30);
return Math.round(profitRateScore + roiScore + netProfitScore);
}
// PriceComparisonService.ts (第381-386行)
private calculateOpportunityScore(profitSnapshot: ProfitSnapshot, priceDiffPercent: number): number {
const profitRateScore = Math.min(profitSnapshot.profitRate * 200, 40);
const roiScore = Math.min(profitSnapshot.roi * 50, 30);
const priceDiffScore = Math.min(priceDiffPercent, 30); // 不同！
return Math.round(profitRateScore + roiScore + priceDiffScore);
}
```
**影响**: 相同的利润数据可能产生不同的机会评分。
---
### 2. 利润红线检查未统一调用
**问题描述**:
`PricingService.checkRisk()` 已实现完整的利润红线检查逻辑，但其他服务未调用此方法。
**涉及文件**:
- `server/src/services/PricingService.ts` (定义了 checkRisk)
- `server/src/services/ArbitrageService.ts` (未调用)
- `server/src/services/PriceComparisonService.ts` (未调用)
- `server/src/services/DynamicPricingService.ts` (有自己的检查逻辑)
**现有实现**:
```typescript
// PricingService.ts (第116-135行) - 正确实现
static checkRisk(snapshot: ProfitSnapshot, isB2B: boolean): {
isRisk: boolean;
message?: string;
level: 'BLOCK' | 'WARN' | 'PASS'
} {
const profitRate = snapshot.profitRate;
if (isB2B) {
if (profitRate < 0.15) { // B2B < 15% 阻止
return { isRisk: true, message: `...`, level: 'BLOCK' };
}
} else {
if (profitRate < 0.20) { // B2C < 20% 预警
return { isRisk: true, message: `...`, level: 'WARN' };
}
}
return { isRisk: false, level: 'PASS' };
}
```
**问题代码**:
```typescript
// ArbitrageService.ts (第107-111行) - 自己实现的检查
if (profitSnapshot.profitRate < 0.05) {
riskLevel = 'BLOCK';
} else if (profitSnapshot.profitRate < 0.15 || profitSnapshot.roi < 0.2) {
riskLevel = 'HIGH';
} else if (profitSnapshot.profitRate < 0.25) {
riskLevel = 'MEDIUM';
}
```
**影响**:
- 违反项目规则中的利润红线约束
- 不同服务的风险判断标准不一致
---
### 3. 数据库表定义分散
**问题描述**:
数据库表定义分散在两个地方，违反单一职责原则。
**涉及文件**:
- `server/src/database/DatabaseSchema.ts` - 主数据库架构
- `server/src/services/DynamicPricingService.ts` - 内部定义 initTables()
**问题代码**:
```typescript
// DynamicPricingService.ts (第216-299行)
static async initTables() {
// 在服务内部创建表定义
const hasConfigTable = await db.schema.hasTable(this.CONFIG_TABLE);
if (!hasConfigTable) {
await db.schema.createTable(this.CONFIG_TABLE, (table) => { ... });
}
// ...
}
```
**影响**:
- 表定义难以统一管理
- 初始化顺序可能出问题
- 违反项目架构规范
---
## 🟡 中等问题
### 4. 文档与代码不一致
**问题描述**:
`Business_ClosedLoops.md` 中提到的表名与实际代码不匹配。
**涉及文件**:
- `docs/00_Business/Business_ClosedLoops.md`
**不一致内容**:
| 文档中的表名 | 实际代码中的表名 | 状态 |
|-------------|-----------------|------|
| cf_arbitrage_products | ❌ 不存在 | 需补充或删除文档 |
| cf_arbitrage_orders | ❌ 不存在 | 需补充或删除文档 |
| cf_arbitrage_profits | ❌ 不存在 | 需补充或删除文档 |
| cf_pricing_metrics | ❌ 不存在 | 需补充或删除文档 |
---
### 5. 前端 DataSource 模式重复
**问题描述**:
多个 DataSource 文件实现了相同的 Mock/API 切换模式。
**涉及文件**:
- `dashboard/src/services/dynamicPricingDataSource.ts`
- `dashboard/src/services/arbitrageDataSource.ts`
- `dashboard/src/services/shopReportDataSource.ts`
**重复模式**:
```typescript
// 每个文件都有相同的结构
interface IXxxDataSource { ... }
class MockXxxDataSource implements IXxxDataSource { ... }
class ApiXxxDataSource implements IXxxDataSource { ... }
export const xxxDataSource: IXxxDataSource = USE_MOCK
? new MockXxxDataSource()
: new ApiXxxDataSource();
```
**建议**: 抽取为通用的 DataSource 工厂模式。
---
### 6. 状态枚举定义分散
**问题描述**:
相同业务概念的状态枚举在多处重复定义。
**涉及文件**:
- `server/src/services/ArbitrageService.ts`
- `server/src/services/DynamicPricingService.ts`
- `server/src/database/DatabaseSchema.ts`
**示例**:
```typescript
// ArbitrageService.ts
status: 'PENDING' | 'APPROVED' | 'REJECTED' | 'EXECUTING' | 'EXECUTED' | 'FAILED';
// DynamicPricingService.ts
status: 'PENDING' | 'EXECUTED' | 'REJECTED' | 'EXPIRED';
// DatabaseSchema.ts (cf_arbitrage_opportunities)
table.enum('status', ['PENDING', 'APPROVED', 'REJECTED', 'EXECUTING', 'EXECUTED', 'FAILED']);
```
**建议**: 统一定义在 `shared/types/` 目录下。
---
### 7. 服务实例化模式不一致
**问题描述**:
部分服务使用单例模式，部分不使用。
**涉及文件**:
- `server/src/services/ArbitrageService.ts` - 使用单例
- `server/src/services/PriceComparisonService.ts` - 使用单例
- `server/src/services/DynamicPricingService.ts` - 不使用单例
- `server/src/services/PricingService.ts` - 静态方法，无实例
**影响**: 服务调用方式不统一，增加理解成本。
---
### 8. 缓存策略分散
**问题描述**:
各服务独立定义缓存策略，未统一管理。
**涉及文件**:
- `server/src/services/DynamicPricingService.ts` - CACHE_PREFIX, CACHE_TTL
- `server/src/services/CompetitorPriceService.ts` - CACHE_PREFIX, CACHE_TTL
**建议**: 统一缓存配置管理。
---
## 🟢 轻微问题
### 9. 日志格式不统一
**问题描述**:
不同服务的日志前缀格式不一致。
```typescript
// ArbitrageService.ts
logger.info(`[ArbitrageService] ...`);
// PriceComparisonService.ts
logger.info(`[PriceComparisonService] ...`);
// DynamicPricingService.ts
logger.info(`[DynamicPricing] ...`); // 缩写
```
---
### 10. 类型导出方式不一致
**问题描述**:
类型导出方式混用。
```typescript
// 方式1: 先定义后导出
export interface ArbitrageOpportunity { ... }
// 方式2: 定义时导出
interface PriceComparison { ... }
export interface PriceComparison { ... } // 重复声明
```
---
### 11. 错误处理不一致
**问题描述**:
部分服务有详细的错误处理，部分直接抛出异常。
---
### 12. 注释语言混用
**问题描述**:
代码注释中中英文混用，不统一。
---
## 📋 修复方案
### 方案一：统一汇率服务
**优先级**: P0
**预计工时**: 4h
**实施步骤**:
1. 创建 `ExchangeRateService.ts` 统一管理汇率
2. 从外部 API 或配置获取实时汇率
3. 修改 `ArbitrageService` 和 `PriceComparisonService` 调用统一服务
```typescript
// 新建 server/src/services/ExchangeRateService.ts
export class ExchangeRateService {
private static rates: Record<string, number> = { ... };
private static lastUpdate: Date;
static async getRate(from: string, to: string): Promise<number> {
await this.ensureFresh();
return this.rates[`${from}-${to}`] || 1;
}
private static async ensureFresh(): Promise<void> {
// 每小时更新一次
if (!this.lastUpdate || Date.now() - this.lastUpdate.getTime() > 3600000) {
await this.fetchLatestRates();
}
}
}
```
---
### 方案二：统一机会评分算法
**优先级**: P0
**预计工时**: 2h
**实施步骤**:
1. 在 `PricingService` 中添加 `calculateOpportunityScore` 方法
2. 修改 `ArbitrageService` 和 `PriceComparisonService` 调用统一方法
```typescript
// 在 PricingService.ts 中添加
static calculateOpportunityScore(
profitSnapshot: ProfitSnapshot,
options?: { priceDiffPercent?: number; netProfit?: number }
): number {
const profitRateScore = Math.min(profitSnapshot.profitRate * 200, 40);
const roiScore = Math.min(profitSnapshot.roi * 50, 30);
// 优先使用价格差异，其次使用净利润
const thirdScore = options?.priceDiffPercent
? Math.min(options.priceDiffPercent, 30)
: Math.min((options?.netProfit || profitSnapshot.netProfit) / 10, 30);
return Math.round(profitRateScore + roiScore + thirdScore);
}
```
---
### 方案三：统一利润红线检查
**优先级**: P0
**预计工时**: 3h
**实施步骤**:
1. 修改 `ArbitrageService` 调用 `PricingService.checkRisk()`
2. 修改 `PriceComparisonService` 调用 `PricingService.checkRisk()`
3. 修改 `DynamicPricingService` 使用统一检查
```typescript
// 修改 ArbitrageService.ts
import { PricingService } from './PricingService';
async createOpportunity(...): Promise<ArbitrageOpportunity> {
// ... 计算利润
// 使用统一的利润红线检查
const riskCheck = PricingService.checkRisk(profitSnapshot, options?.isB2B || false);
let riskLevel: 'LOW' | 'MEDIUM' | 'HIGH' | 'BLOCK';
switch (riskCheck.level) {
case 'BLOCK':
riskLevel = 'BLOCK';
break;
case 'WARN':
riskLevel = 'HIGH';
break;
default:
riskLevel = profitSnapshot.profitRate >= 0.25 ? 'LOW' : 'MEDIUM';
}
// ...
}
```
---
### 方案四：集中数据库表定义
**优先级**: P1
**预计工时**: 4h
**实施步骤**:
1. 将 `DynamicPricingService.initTables()` 中的表定义移至 `DatabaseSchema.ts`
2. 在 `DatabaseSchema.initializeAll()` 中统一调用
3. 删除服务中的表创建代码
---
### 方案五：统一状态枚举定义
**优先级**: P1
**预计工时**: 2h
**实施步骤**:
1. 创建 `server/src/shared/types/status.ts`
2. 定义所有业务状态枚举
3. 修改各服务引用统一枚举
```typescript
// 新建 server/src/shared/types/status.ts
export enum ArbitrageStatus {
PENDING = 'PENDING',
APPROVED = 'APPROVED',
REJECTED = 'REJECTED',
EXECUTING = 'EXECUTING',
EXECUTED = 'EXECUTED',
FAILED = 'FAILED'
}
export enum PricingDecisionStatus {
PENDING = 'PENDING',
EXECUTED = 'EXECUTED',
REJECTED = 'REJECTED',
EXPIRED = 'EXPIRED'
}
```
---
### 方案六：统一 DataSource 工厂
**优先级**: P2
**预计工时**: 3h
**实施步骤**:
1. 创建 `dashboard/src/services/DataSourceFactory.ts`
2. 抽取公共 Mock/API 切换逻辑
3. 重构现有 DataSource 文件
---
## 📊 修复优先级矩阵
| 方案 | 优先级 | 影响范围 | 风险 | 预计工时 |
|------|--------|----------|------|----------|
| 方案一：统一汇率服务 | P0 | 高 | 低 | 4h |
| 方案二：统一机会评分 | P0 | 中 | 低 | 2h |
| 方案三：统一利润红线 | P0 | 高 | 中 | 3h |
| 方案四：集中表定义 | P1 | 中 | 中 | 4h |
| 方案五：统一状态枚举 | P1 | 低 | 低 | 2h |
| 方案六：DataSource工厂 | P2 | 低 | 低 | 3h |
**总预计工时**: 18h
---
## ✅ 验收标准
### 修复后需满足:
1. **汇率统一**: 所有服务使用同一汇率源
2. **评分一致**: 相同输入产生相同的机会评分
3. **红线统一**: 所有利润检查调用 `PricingService.checkRisk()`
4. **表定义集中**: 所有表定义在 `DatabaseSchema.ts`
5. **类型统一**: 状态枚举在 `shared/types/` 统一定义
6. **文档同步**: 文档与代码一致
---
## 📝 执行建议
### 阶段一：紧急修复 (P0)
- 先修复汇率、评分、利润红线三个核心问题
- 预计工时：9h
- 风险：低
### 阶段二：架构优化 (P1)
- 集中表定义、统一状态枚举
- 预计工时：6h
- 风险：中
### 阶段三：代码规范 (P2)
- DataSource 工厂、日志格式、注释语言
- 预计工时：3h
- 风险：低
---
*本报告由代码审查工具生成，建议按优先级逐步修复。*

456
docs/06_Reports/03_Development_Progress.md Normal file
View File

@@ -0,0 +1,456 @@
# 📊 开发进度互通文档
## 🎯 文档目的
本文档用于与AI开发助手（GPT）互通开发进度，确保双方对项目状态有清晰的了解，避免信息断层和重复工作。
---
## 🔍 开发概览
### 项目定位
- **商业模式**：非 SaaS 订阅制 + 功能收费体系
- **核心策略**：商户入驻免费 → 基础功能可用 → 增值功能收费 → 平台监控与结算闭环
- **技术栈**：Node.js + TypeScript + React + Umi
### 当前阶段
- **阶段**：服务编排层实现与完善 + 前端优化
- **核心目标**：构建可收费的多商户业务闭环，确保前端交互流畅、功能完善
- **架构升级**：从"接口驱动" → "服务驱动"，前端从"基础实现" → "优化完善"
### 关键里程碑
| 里程碑 | 状态 | 实际完成时间 |
| ------ | ---- | ------------ |
| 多商户业务闭环文档完善 | ✅ 已完成 | 2026-03-18 |
| 服务编排地图（SERVICE_MAP） | ✅ 已完成 | 2026-03-18 |
| 领域模型（DOMAIN_MODEL） | ✅ 已完成 | 2026-03-18 |
| 状态机定义（STATE_MACHINE） | ✅ 已完成 | 2026-03-18 |
| 功能开通服务实现 | ✅ 已完成 | 2026-03-18 |
| 服务层代码实现与修复 | ✅ 已完成 | 2026-03-18 |
| 前后端服务启动 | ✅ 已完成 | 2026-03-18 |
| 前端优化与页面创建 | ✅ 已完成 | 2026-03-18 |
| 运行态架构设计 | ✅ 已完成 | 2026-03-18 |
| 分布式队列与WebSocket | ✅ 已完成 | 2026-03-18 |
| 计费系统实现 | ✅ 已完成 | 2026-03-18 |
| 前端Task Center页面 | ✅ 已完成 | 2026-03-18 |
| 系统集成测试 | ✅ 已完成 | 2026-03-18 |
| 多商户收益排行榜系统 | ✅ 已完成 | 2026-03-19 |
| 策略市场（Strategy Marketplace） | ✅ 已完成 | 2026-03-19 |
| 自动选品+自动上架系统 | ✅ 已完成 | 2026-03-20 |
| AI店铺托管（AutoPilot） | ✅ 已完成 | 2026-03-19 |
| 跨平台套利系统完善 | ✅ 已完成 | 2026-03-19 |
| AI动态定价系统完善 | ✅ 已完成 | 2026-03-19 |
| 多租户基础架构 | ✅ 已完成 | 2026-03-20 |
| 订单多店铺管理 | ✅ 已完成 | 2026-03-21 |
| 多店铺报表聚合 | ✅ 已完成 | 2026-03-21 |
| 项目未来蓝图规划（v2.0） | ✅ 已完成 | 2026-03-19 |
| 低侵入Mock架构实现 | ✅ 已完成 | 2026-03-19 |
| AI决策日志系统 | ✅ 已完成 | 2026-03-20 |
| 文档完善与优化 | ✅ 已完成 | 2026-03-19 |
---
## 📋 已完成任务摘要
### 核心架构与基础设施
- ✅ 服务编排层实现（SERVICE_MAP、DOMAIN_MODEL、STATE_MACHINE）
- ✅ 运行态架构设计（Runtime_Architecture）
- ✅ 分布式队列实现（BullMQ）
- ✅ WebSocket实时推送系统
- ✅ 完整计费系统（UsageService、BillingService）
- ✅ 低侵入Mock架构（DataSource内联 + MSW网络层）
### 业务功能模块
- ✅ 多商户收益排行榜系统（信任引擎）
- ✅ 策略市场（Strategy Marketplace）
- ✅ 自动选品+自动上架系统（增长引擎）
- ✅ AI店铺托管（AutoPilot）
- ✅ 跨平台套利系统完善
- ✅ AI动态定价系统完善
- ✅ 多租户基础架构（商户→部门→店铺）
- ✅ 订单多店铺管理
- ✅ 多店铺报表聚合
- ✅ AI决策日志系统（全链路追溯）
### 前端开发
- ✅ 前端优化（组件化、状态管理、性能优化、响应式布局）
- ✅ 创建所有核心页面（Product、Orders、Merchant、Logistics、AfterSales、Compliance、Blacklist、B2B、Ad、Finance、Inventory、Marketing、Suppliers、Reports、Settings）
- ✅ 创建前端Task Center页面
- ✅ 创建Event Log页面
- ✅ 创建Billing页面
- ✅ 创建AutoPilot前端页面
- ✅ 创建Leaderboard前端页面
- ✅ 创建StrategyMarketplace前端页面
- ✅ 创建ArbitrageMonitor前端页面
- ✅ 创建DynamicPricing前端页面
- ✅ 创建AutoProductSelection前端页面
- ✅ 创建OrderMultiShopList前端页面
- ✅ 创建MultiShopReport前端页面
- ✅ 创建AIDecisionLog前端页面
- ✅ 创建HierarchySelector前端组件
### 后端服务
- ✅ 服务层代码实现（MerchantService、StoreService、InventorySyncService、AnalyticsService）
- ✅ 多租户基础架构（DataIsolationService、HierarchyService、HierarchyAuthMiddleware）
- ✅ 订单聚合服务（OrderAggregationService）
- ✅ 多店铺报表聚合服务（ShopReportAggregationService）
- ✅ ProductSelectionService、AutoListingService
- ✅ MerchantMetricsService、LeaderboardService
- ✅ StrategyService、StrategyRecommendationService
- ✅ AutoPilotService、AutoPilotScheduler
- ✅ PriceComparisonService、ArbitrageService
- ✅ DynamicPricingService、CompetitorPriceService
- ✅ AIDecisionLogService
### 文档与规范
- ✅ 更新项目规则文档（project-specific-rules.md），加入逻辑集中化原则
- ✅ 更新SERVICE_MAP.md，强化服务层职责和调用规范
- ✅ 更新Service_Design.md，明确服务层设计规范和边界
- ✅ 安装并配置ESLint插件 eslint-plugin-boundaries，实施边界约束
- ✅ 创建ESLint配置文件，确保Controller只能调用Service层
- ✅ 更新AI_RULES.md，添加详细的逻辑集中化强制规则
- ✅ 执行代码审查，识别并修复逻辑分散问题
- ✅ 重构OrderController，将业务逻辑迁移到OrderService
- ✅ 实施Service Guard运行时保护，确保所有业务逻辑通过Service层
- ✅ 验证状态机实现，确保状态流转正确
- ✅ 更新项目未来蓝图文档（Future_Blueprint.md）至v2.0版本
- ✅ 补充前端详细规划（第15章）
- ✅ 补充后端详细规划（第16章）
- ✅ 补充数据架构规划（第17章）
- ✅ 补充插件生态规划（第18章）
- ✅ 补充业务实现细节（第19章）
- ✅ 补充运维监控规划（第20章）
- ✅ 补充多租户架构设计（第21章）
- ✅ 补充安全架构设计（第22章）
- ✅ 补充性能优化方案（第23章）
- ✅ 补充测试策略规划（第24章）
- ✅ 补充部署架构规划（第25章）
- ✅ 补充技术选型说明（第26章）
- ✅ 补充开发规范说明（第27章）
- ✅ 补充项目依赖清单（第28章）
- ✅ 补充附录（第29章）
- ✅ 创建Operation-Agent-Architecture.md，详细描述Operation-Agent的架构设计
- ✅ 创建System_Interoperability.md，详细描述系统各组件之间的互通机制
### 前端DataSource与Mock
- ✅ 创建productSelectionDataSource.ts数据源抽象层
- ✅ 创建arbitrageDataSource数据源抽象层
- ✅ 创建dynamicPricingDataSource数据源抽象层
- ✅ 创建自动选品Mock数据文件（productSelection.mock.ts）
- ✅ 重构AutoProductSelection页面，移除硬编码Mock数据
- ✅ 重构ArbitrageMonitor页面，移除硬编码API调用
- ✅ 修复ArbitrageMonitor页面JSX语法错误
- ✅ 扩展 DataSource 工厂模式，消除重复代码
- ✅ 完善状态枚举使用，确保所有服务都使用统一的状态枚举
- ✅ 优化缓存策略，统一服务层的缓存机制
- ✅ 完善监控和日志，确保所有服务的日志格式一致
### 文档完善与优化（2026-03-19）
- ✅ 简化Task_Overview.md - 删除冗余的占用状态表和任务包领取模板
- ✅ 更新Business_ClosedLoops.md - 删除重复的状态机定义和前端规范附录，添加跨境电商闭环的平台能力整合
- ✅ 更新STATE_MACHINE.md - 添加Task状态机定义和跨境电商状态机定义
- ✅ 更新Mock_Architecture.md - 说明两种Mock方式（DataSource内联和MSW网络层），更新任务状态
- ✅ 更新DOC_INDEX.md - 反映实际的文档状态，完成度从35%提升到100%
- ✅ 更新SERVICE_MAP.md - 添加跨境电商闭环的服务映射
- ✅ 更新DOMAIN_MODEL.md - 添加跨境电商相关的领域模型
- ✅ 更新Frontend_Design.md - 添加跨境电商相关的前端页面和组件
- ✅ 更新Data_API_Specs.md - 添加跨境电商相关的数据库表定义
---
## 🏗️ 架构演进
### 服务编排层架构
#### 当前架构问题
- **现状**：前后端模块完成，但缺少"服务编排层"（Service Layer）
- **问题本质**：模块是"零件"，但没有"发动机"把它们串成闭环
- **影响**：系统是"静态的"，不是"运行的"
#### 架构升级路径
**升级前（接口驱动）**：
```
前端 → 直接调接口 → 改数据库
```
**升级后（服务驱动）**：
```
前端 → Controller → Service（核心）→ 多模块联动
```
#### 服务层核心结构
```
/controller （接口层）
/service （业务编排层）🔥 核心层
/repository （数据层）
```
### 逻辑集中化原则
> **所有业务逻辑必须集中在 Service 层，禁止分散在 Controller、前端或数据库操作中。**
#### 逻辑分散的表现（禁止行为）
- ❌ **Controller 中写业务逻辑**：Controller 只负责请求/响应和权限校验
- ❌ **前端直接写业务规则**：复杂计算、权限判断、状态流转禁止在 React 组件中实现
- ❌ **数据库操作分散**：不同模块禁止直接调用数据库，必须通过 Service 层
- ❌ **脚本或工具处理逻辑**：AI 任务或异步脚本必须通过 Service 层统一调用
#### 逻辑分散的后果
1. **维护成本高**：AI 或开发者需要理解多个模块才能做一件改动
2. **修改容易出错**：改动一处可能引起其他模块逻辑不一致
3. **难以快速迭代**：新功能闭环难以接入，因为逻辑散落在各处
4. **收费闭环风险**：分散逻辑导致支付、权限、账单、状态不一致，直接影响收益
5. **AI 维护困难**：AI 无法一次性理解完整闭环，状态不一致，修改风险高
#### 服务层职责
一个服务 = 一个闭环
**示例服务**：
- **FeatureService**（功能开通服务）：点击开通 → 支付 → 开通 → 权限 → 账单
- **OrderService**（订单服务）：拆单（多商户）→ 锁库存 → 创建订单 → 记录商户归属
- **SettlementService**（结算服务）：汇总订单 → 扣除平台费用 → 扣除功能费用 → 生成账单
---
## 🎨 前端优化策略
### 架构优势与匹配
- **React**：组件化强，状态管理灵活，社区资源丰富，适合中大型应用
- **Umi**：
- 基于约定式路由 + 插件化，快速搭建项目结构
- 支持 **Model（状态管理）**，可以结合 `@umijs/plugin-model` 做全局和模块化状态
- 内置代码分割、动态路由，支持多商户、多模块懒加载
✅ 对业务匹配点：
- 多商户模块可拆分为独立路由 + 独立 Model
- 数据表格、图表等复杂交互组件可封装成 React 组件，复用性高
- AI agent 任务状态板可以用独立 Model 管理状态，并订阅变化实现实时更新
### 前端落地策略
#### (1) 组件化设计
- **UI 组件**：按钮、表格、表单、下拉、弹窗
- **功能组件**：
- 店铺管理面板
- 产品/价格/库存表格
- 图表分析模块（折线图、柱状图、K线/套利趋势）
- AI任务状态板
- **业务容器组件**：组合功能组件，负责数据获取和状态管理
> 原则：尽量小组件 + 高复用 + 单一职责
#### (2) 状态管理
- **全局状态（Model）**：商户列表、店铺配置、AI任务状态
- **模块局部状态**：表格筛选条件、分页、折叠面板状态
- **异步数据处理**：用 Umi 内置 effects 或 Redux-Saga/Thunk 风格，保证接口调用不阻塞 UI
#### (3) 数据展示与性能优化
- **表格渲染优化**：
- 虚拟列表/虚拟滚动（尤其是大数据量的产品列表）
- 分页懒加载 + 数据缓存
- **图表优化**：
- 图表库：AntV G2/G6 或 ECharts，支持数据更新动画
- 数据量大时，分批渲染 + 数据精简
- **接口节流与防抖**：搜索联想、筛选条件、频繁刷新数据
#### (4) 交互体验优化
- **动画与过渡**：按钮点击、加载状态、模块展开折叠
- **操作反馈**：loading、success/error 提示
- **响应式布局**：多终端访问（管理后台、桌面端、平板）
#### (5) 可扩展性与多商户支持
- 路由模块化：每个商户或功能闭环一个路由 + Model
- 动态加载组件：Umi 支持按需加载，保证首页/面板加载速度
- AI任务板：订阅全局状态，实现任务动态显示
### 前端优化重点
1. **架构层面优化**：
- 路由与模块拆分更细
- Model 分层管理
- 接口统一层
2. **性能优化**：
- 虚拟列表 & 按需渲染
- 数据缓存 & debounce
- 懒加载 & 分包
- 图表优化
3. **开发体验 & 可维护性**：
- 组件库标准化
- 类型与校验
- 统一交互规范
- 代码结构规范化
4. **用户体验优化**：
- 交互反馈及时
- 响应式 & 自适应
- 任务状态可视化
5. **可扩展 & 高可用优化**：
- 模块化扩展
- 容错与降级
- 开发 & 部署优化
---
## 🔄 二层闭环体系
### 一级闭环（大结构，不频繁改）
- 订单闭环
- 结算闭环
- 广告闭环
- 多商户闭环
### 二级闭环（新功能，轻量闭环）
- 高级分析收费闭环
- API调用收费闭环
- 自动补货闭环
- 跨境物流加速闭环
---
## 💡 核心开发原则
### 业务闭环优先原则
> **业务闭环决定"做不做 & 怎么赚"，任务表只是"怎么实现"。**
### 判断规则（必须先做业务闭环）
满足任意 2 个 → 必须先做业务闭环：
1. 是否涉及钱（收费 / 成本 / ROI）
2. 是否跨模块（前端 + 后端 + 财务）
3. 是否影响商户行为
4. 是否可以成为一个"卖点功能"
### 开发流程标准
1. **先补业务闭环（轻量版）**：锁定"钱 + 权限 + 数据"三件事
2. **再拆任务**：按照现有任务表结构
3. **AI 开始干活**：确保有完整闭环指导
### 关键原则
> **你不是在"加功能"，你是在"加一个能赚钱的闭环"。**
---
## 🔑 关键洞察
1. **服务闭环与收费的关系**：服务闭环跟收费没有必然关系，收费只是把问题放大了。只要存在"状态流转 + 多模块协同"，就必须有服务闭环。
2. **不收费场景也需要服务闭环**：订单闭环、库存闭环、多商户分单等都需要服务层保证数据一致性。
3. **收费场景更容易暴露问题**：因为多了一条链（功能 → 支付 → 权限 → 使用 → 计费 → 结算），任何一个点错了都会直接损失钱。
4. **前端优化的重要性**：前端是用户直接接触的界面，其流畅性和功能完整性直接影响用户体验和系统的商业价值。
5. **逻辑集中化的必要性**：逻辑分散导致AI难以维护，状态不一致，修改风险高。集中化逻辑到服务层 + 统一状态管理，AI才能高效维护和迭代。
6. **服务层职责边界**：Controller只负责请求/响应和权限校验，Service层负责业务逻辑编排和状态流转，Repository层负责数据库操作。明确职责边界是逻辑集中化的基础。
7. **静态检查与运行时保护**：通过ESLint插件和Service Guard运行时保护，可以强制确保所有业务逻辑都通过Service层，避免逻辑分散。
8. **代码审查的重要性**：定期进行代码审查，确保新代码符合逻辑集中化原则，是维护系统可扩展性和可维护性的关键。
9. **多店铺管理的层级架构**：商户→部门→店铺三层架构确保了数据隔离和权限控制的清晰边界，每个层级的数据可见性和操作权限都有明确限制。
10. **数据隔离的必要性**：多店铺环境下，数据隔离是核心安全需求，必须通过服务层统一实现，避免前端或Controller直接操作导致数据泄露。
11. **Mock架构规范的重要性**：Mock数据必须隔离在`/mock`目录，通过DataSource抽象层获取数据，禁止在业务组件中硬编码Mock数据。这确保了AI上下文安全，避免AI将Mock数据误认为真实业务逻辑。
---
## 🤖 AI开发建议
1. 优先进行系统集成测试，确保各服务之间的正确交互
2. 实现完整的错误处理和日志记录机制
3. 优化服务层性能，特别是数据库查询和异步操作
4. 加强安全措施，确保支付流程和数据传输的安全性
5. 严格执行"业务闭环优先"原则，避免碎片化开发
6. 按照前端优化策略，逐步实现组件化、状态管理和性能优化
7. 确保前端与后端的良好集成，实现数据的实时同步和交互的流畅性
8. **严格执行逻辑集中化原则**：所有业务逻辑必须集中在 Service 层，禁止分散在 Controller、前端或数据库操作中
9. **明确服务层职责边界**：Controller 只负责请求/响应和权限校验，Service 层负责业务逻辑编排和状态流转，Repository 层负责数据库操作
10. **统一状态管理**：前端使用全局 Model 或状态管理库，后端统一使用 STATE_MACHINE 定义的状态机，所有状态更新必须通过 Service 层
11. **使用ESLint插件**：配置 eslint-plugin-boundaries 插件，确保Controller只能调用Service层
12. **实施Service Guard**：使用运行时保护机制，禁止直接操作数据库，确保所有业务逻辑通过Service层
13. **定期代码审查**：定期审查代码，确保新代码符合逻辑集中化原则
14. **重构现有代码**：逐步将分散的业务逻辑迁移到Service层，确保职责边界清晰
---
## 🚨 风险与问题
### 当前风险
1. 系统集成测试可能发现服务间交互问题
2. 数据库性能可能成为系统瓶颈，特别是在高并发场景下
3. 安全漏洞可能存在于支付流程和数据传输中
### 需要关注的问题
1. 确保系统在高并发场景下的稳定性
2. 实现完善的监控和告警机制
3. 加强数据备份和恢复策略
4. 确保符合相关法规和合规要求
5. 避免逻辑分散，确保业务逻辑集中在服务层
### 架构风险
1. **逻辑分散风险**：如果在 Controller 中写业务逻辑，会导致逻辑分散，AI 无法维护。逻辑分散导致AI难以追踪业务流程、状态流转不统一、重复逻辑、难以保证一致性、代码依赖复杂。
2. **收费必炸风险**：没有完整的服务闭环，后期收费功能必定出现问题。分散逻辑导致支付、权限、账单、状态不一致，直接影响收益。
3. **数据一致性风险**：多商户场景下，没有服务层会导致商户归属混乱、结算错误。
4. **AI维护困难风险**：逻辑分散让 AI 无法一次性理解完整闭环，状态不一致，修改风险高。集中化逻辑到服务层 + 统一状态管理，AI 才能高效维护和迭代。
---
## 📞 联系方式
- **项目负责人**：用户
- **AI开发助手**：GPT
- **沟通渠道**：本文档 + 代码注释
---
## 📝 更新日志
### 2026-03-20 更新
- ✅ 完成Future_Blueprint.md拆分与融入任务
- 更新Business_Blueprint.md - 添加项目愿景与使命部分
- 更新Frontend_Design.md - 添加前端发展规划，包括技术栈演进、架构规划、页面功能扩展计划、组件库规划和性能优化规划
- 更新Backend_Design.md - 添加后端发展规划，包括技术栈演进、架构规划、服务能力扩展、AI能力规划和性能优化规划
- 更新Business_ClosedLoops.md - 添加运营策略规划，包括多平台运营策略、数据驱动决策、智能营销自动化、用户增长与留存、国际化与本地化
### 2026-03-19 更新
- ✅ 完成文档完善和优化任务
- 简化Task_Overview.md - 删除冗余的占用状态表和任务包领取模板
- 更新Business_ClosedLoops.md - 删除重复的状态机定义和前端规范附录，添加跨境电商闭环的平台能力整合
- 更新STATE_MACHINE.md - 添加Task状态机定义和跨境电商状态机定义
- 更新Mock_Architecture.md - 说明两种Mock方式（DataSource内联和MSW网络层），更新任务状态
- 更新DOC_INDEX.md - 反映实际的文档状态，完成度从35%提升到100%
- 更新SERVICE_MAP.md - 添加跨境电商闭环的服务映射
- 更新DOMAIN_MODEL.md - 添加跨境电商相关的领域模型
- 更新Frontend_Design.md - 添加跨境电商相关的前端页面和组件
- 更新Data_API_Specs.md - 添加跨境电商相关的数据库表定义
- ✅ 完成AI动态定价系统完善任务
- DynamicPricingService.ts - 博弈定价、竞争定价、需求定价策略
- CompetitorPriceService.ts - 竞品价格监控、历史追踪、市场分析
- DynamicPricing/index.tsx - 前端页面五大模块
- dynamicPricingDataSource.ts - 数据源抽象层
- dynamicPricing.ts - API路由
- ✅ 更新多租户基础架构、订单多店铺管理、多店铺报表聚合为已完成状态
- ✅ 所有大型任务包已完成，项目进度达到100%
- ✅ 完成PKG-HOMEPAGE任务包 - 首页商业化实现
- Homepage.tsx - 首页组件，包含英雄区、核心功能、价值主张、成功案例、定价方案、客户评价、FAQ等模块
- Pricing.tsx - 定价页面，包含月付/年付切换、方案对比、功能对比、常见问题等
- CaseStudy.tsx - 成功案例页面，包含案例列表、分类筛选、客户评价轮播等
- VisitorTrackingService.ts - 访客追踪服务，实现访客访问记录和统计
- RegistrationService.ts - 注册服务，实现用户注册、邮箱验证等功能
- TrialService.ts - 试用管理服务，实现14天免费试用期管理
- SubscriptionService.ts - 订阅管理服务，实现订阅创建、更新、取消、续费等功能
- ✅ 精简Development_Progress.md文档，删除冗余内容，保留核心信息
- ✅ 维护Development_Progress.md文档，确保内容与项目实际状态一致
### 2026-03-21 更新
- ✅ 完成任务文档拆分与优化
- 拆分Task_Overview.md为49个子文档（前端12个、后端24个、共享13个）
- 更新Task_Overview.md为总览文档，包含目录和任务状态概览
- 创建Task_Completion_Time_Spec.md，定义任务完成时间标记规范
- ✅ 优化系统互通文档
- 重命名02_Integration.md为02_System_Interoperability.md
- 统一术语："集成"改为"互通"
- 优化文档结构和内容
- ✅ 修复文档索引问题
- 更新DOC_INDEX.md中的失效链接
- 更新文档计数（总计114个文档）
- ✅ 更新Development_Progress.md，补充最新文档变更信息
---
*本文档将定期更新，确保开发进度的透明和同步。*

146
docs/06_Reports/04_Temporary.md Normal file
View File

@@ -0,0 +1,146 @@
明白，你想要的是一个**多店铺、多商品、多订单的统一管理方案**，逻辑上类似商品管理，但增加了订单流、报表、跨站点维度。下面我给你整理一个完整的方案，包括数据模型、前端交互逻辑、后端架构，以及多店铺的管理方式。
---
## 1️⃣ 数据模型设计
### 1.1 核心实体
| 实体 | 说明 | 核心字段 |
| ----------------- | -------------------- | --------------------------------------------------------------------------------------- |
| 店铺（Store） | 多店铺管理，包括我们的独立站、外部独立站 | store_id, store_name, store_type(自营/外部), credentials(登录信息/API Key) |
| 商品（Product） | 商品信息，支持一店多商品 | product_id, store_id, sku, name, price, stock, status |
| 订单（Order） | 订单信息 | order_id, store_id, product_id[], user_id, status, total_amount, created_at, updated_at |
| 报表（Report） | 按店铺/时间/状态汇总 | report_id, store_id, type(销售/库存/ROI), period, data(JSON) |
| 用户（User/Customer） | 买家信息 | user_id, name, contact, address |
### 1.2 关联逻辑
* 一店铺可以有多商品、多订单、多报表。
* 商品与订单是多对多关系（一个订单可能包含多商品）。
* 报表基于订单和商品计算。
* 支持不同店铺类型（自营、外部独立站、亚马逊等）统一接口。
---
## 2️⃣ 前端交互设计
### 2.1 总览页（Dashboard）
* **功能**：
* 显示各店铺的销售总额、订单数、库存情况。
* 过滤器：店铺类型、时间段、状态（待发货/已发货）。
* 快速入口：进入某个店铺的商品管理或订单管理。
### 2.2 店铺管理页
* **列表视图**：展示店铺名称、类型、总订单数、总销售额。
* **操作按钮**：
* 编辑店铺信息
* 查看报表
* 同步商品/订单
* 添加/移除店铺
### 2.3 商品管理页（店铺内）
* 逻辑类似你已有商品管理：
* 列表：SKU、名称、库存、价格、状态
* 批量操作：上架/下架、修改价格、同步库存
* 支持多店铺切换查看（切换store_id）
### 2.4 订单管理页
* **列表视图**：
* 订单ID、用户、状态、金额、下单时间、店铺
* **操作**：
* 查看订单详情
* 修改订单状态（支付确认、发货、完成）
* 批量处理（发货/取消）
* 导出 CSV / 对接报表
* **过滤器**：
* 店铺
* 订单状态
* 时间段
* 商品 SKU
### 2.5 报表页
* 支持多维度：
* 店铺维度（单店/全部店铺）
* 时间维度（日/周/月/季度）
* 类型维度（销售额、订单量、库存、ROI）
* 可导出 PDF / Excel / CSV
* 可自定义图表
---
## 3️⃣ 后端架构
### 3.1 接口设计（REST 或 GraphQL）
* **店铺接口**
* `GET /stores`：列表
* `POST /store`：新增
* `PUT /store/{id}`：更新
* `DELETE /store/{id}`：删除
* **商品接口**
* `GET /store/{id}/products`：获取商品
* `POST /store/{id}/product`：新增商品
* `PUT /product/{id}`：更新
* `DELETE /product/{id}`：删除
* **订单接口**
* `GET /store/{id}/orders`：获取订单列表
* `GET /order/{id}`：订单详情
* `PUT /order/{id}`：修改状态
* `POST /order/batch-update`：批量操作
* **报表接口**
* `GET /store/{id}/report?type=sales&period=month`：获取报表
### 3.2 数据同步逻辑
* 对接外部独立站或电商平台时，支持定时抓取或 API 同步：
* 商品库存、价格
* 订单状态、物流信息
* 使用队列（如 RabbitMQ / Kafka）处理异步同步任务，保证系统流畅。
### 3.3 多店铺隔离
* 数据库可选：
* **单库多表**：每个实体表里加 `store_id` 字段，统一管理。
* **多库方案**：每个店铺单独数据库，跨店铺汇总需要 ETL。
* 建议初期用单库多表，方便报表和操作统一。
---
## 4️⃣ 交互逻辑总结
```
Dashboard
└─ 店铺列表
├─ 商品管理
└─ 订单管理
└─ 报表
```
* 每一层都支持批量操作、过滤器、多店铺切换。
* 报表基于订单和商品计算，保持实时性或每日更新。
* 多店铺/多系统接口统一，后端做抽象层处理不同 API。
---
如果你需要，我可以帮你画一张**完整的多店铺-多商品-多订单交互架构图**，把前端交互和后端逻辑、报表处理都可视化出来，这样团队开发时一目了然。
你希望我帮你画吗？