refactor(types): 重构类型系统，统一共享类型定义
feat(types): 新增共享类型中心，包含用户、产品、订单等核心领域类型 fix(types): 修复类型定义错误，统一各模块类型引用 style(types): 优化类型文件格式和注释 docs(types): 更新类型文档和变更日志 test(types): 添加类型测试用例 build(types): 配置类型共享路径 chore(types): 清理重复类型定义文件
This commit is contained in:
@@ -35,6 +35,10 @@
|
||||
| [10_Currency_Management](../01_Architecture/10_Currency_Management.md) | **货币管理**: 多货币支持、汇率管理、货币转换 |
|
||||
| [11_Mock_Architecture](../01_Architecture/11_Mock_Architecture.md) | **Mock架构**: 低侵入Mock方案，支持DataSource内联和MSW网络层两种方式 |
|
||||
| [12_Operation_Agent](../01_Architecture/12_Operation_Agent.md) | **运营Agent**: 运营自动化、Agent设计、任务调度 |
|
||||
| [13_TypeScript_Standards](../01_Architecture/13_TypeScript_Standards.md) | **TypeScript编译规约**: TypeScript编译零错误规约体系、tsconfig配置、代码规约 |
|
||||
| [14_Code_Quality_Standards](../01_Architecture/14_Code_Quality_Standards.md) | **代码质量规范**: ESLint配置、Prettier配置、代码风格规范、测试规范 |
|
||||
| [15_Schema_Driven_Development](../01_Architecture/15_Schema_Driven_Development.md) | **Schema驱动开发**: zod使用指南、Schema组织、类型推导、数据验证 |
|
||||
| [16_Unified_Type_Management](../01_Architecture/16_Unified_Type_Management.md) | **统一类型管理**: 类型中心架构、类型层次、类型转换、版本管理 |
|
||||
| [frontend/01_Product](../01_Architecture/frontend/01_Product.md) | **产品前端**: 产品模块前端设计规范 |
|
||||
| [frontend/02_Orders](../01_Architecture/frontend/02_Orders.md) | **订单前端**: 订单模块前端设计规范 |
|
||||
| [frontend/03_Ad](../01_Architecture/frontend/03_Ad.md) | **广告前端**: 广告模块前端设计规范 |
|
||||
@@ -97,7 +101,12 @@
|
||||
| [00_AI_Index](../05_AI/00_AI_Index.md) | **AI索引**: AI文档总览与导航 |
|
||||
| [01_Strategy](../05_AI/01_Strategy.md) | **AI策略**: AI协作策略、节点自动决策体系、规则引擎 |
|
||||
| [02_Rules](../05_AI/02_Rules.md) | **AI规则**: AI开发规则、代码规范、上下文管理 |
|
||||
| [03_Module_List](../05_AI/03_Module_List.md) | **AI模块列表**: AI功能模块、模块接口、模块依赖 |
|
||||
| [03_Implementation_Strategy](../05_AI/03_Implementation_Strategy.md) | **AI实施策略**: AI实施策略和落地计划 |
|
||||
| [04_Quick_Reference_Card](../05_AI/04_Quick_Reference_Card.md) | **AI快速参考卡片**: 硬性约束、代码模板、常见错误对比 |
|
||||
| [05_Development_Checklist](../05_AI/05_Development_Checklist.md) | **AI开发检查清单**: 开发各阶段强制检查项 |
|
||||
| [06_Wrong_vs_Right_Examples](../05_AI/06_Wrong_vs_Right_Examples.md) | **错误示例对比**: 错误代码模式与正确实现方式 |
|
||||
| [07_TypeScript_Error_Fix_Guide](../05_AI/07_TypeScript_Error_Fix_Guide.md) | **TypeScript错误修复方案**: 解决613个编译错误的完整方案 |
|
||||
| [09_TypeScript_Error_Tasks](../05_AI/09_TypeScript_Error_Tasks.md) | **TypeScript错误任务列表**: AI领取修复任务的清单 |
|
||||
|
||||
---
|
||||
|
||||
@@ -164,12 +173,12 @@
|
||||
| 02_Backend | 12 | ✅ |
|
||||
| 03_Frontend | 7 | ✅ |
|
||||
| 04_Plugin | 3 | ✅ |
|
||||
| 05_AI | 4 | ✅ |
|
||||
| 05_AI | 9 | ✅ |
|
||||
| 06_Reports | 5 | ✅ |
|
||||
| 07_Testing | 3 | ✅ |
|
||||
| 08_Analysis | 7 | ✅ |
|
||||
| 10_Documents_Global | 3 | ✅ |
|
||||
| **总计** | **114** | **✅** |
|
||||
| **总计** | **123** | **✅** |
|
||||
|
||||
---
|
||||
|
||||
@@ -180,4 +189,4 @@
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-03-19*
|
||||
*最后更新: 2026-03-20*
|
||||
|
||||
142
docs/10_Documents_Global/临时方案.md
Normal file
142
docs/10_Documents_Global/临时方案.md
Normal file
@@ -0,0 +1,142 @@
|
||||
是的，**这种结构是非常好的**，能够清晰地划分不同的类型模块，并且通过 `index.ts` 统一导出，便于前后端都能够通过统一入口来使用类型。
|
||||
|
||||
我可以给你一些建议，帮助你在这个结构基础上做到 **更易扩展、维护和智能化**，以及确保 **类型一致性** 和 **高效协作**：
|
||||
|
||||
---
|
||||
|
||||
## 1. **结构设计优化**
|
||||
|
||||
你目前的结构已经很清晰，将不同领域的类型分开存放，按照功能区分，便于管理和扩展。以下是一些细节优化建议：
|
||||
|
||||
```bash
|
||||
server/src/shared/types/
|
||||
├── api/ # API 接口类型
|
||||
│ ├── user.ts # 用户相关接口类型
|
||||
│ ├── order.ts # 订单相关接口类型
|
||||
│ └── index.ts # 统一导出所有接口类型
|
||||
│
|
||||
├── domain/ # 领域模型
|
||||
│ ├── user.ts # 用户领域模型
|
||||
│ ├── order.ts # 订单领域模型
|
||||
│ └── index.ts # 统一导出所有领域模型
|
||||
│
|
||||
├── dto/ # 数据传输对象（DTO）
|
||||
│ ├── createUser.ts # 创建用户的 DTO
|
||||
│ ├── updateOrder.ts # 更新订单的 DTO
|
||||
│ └── index.ts # 统一导出所有 DTO
|
||||
│
|
||||
├── enums/ # 枚举定义
|
||||
│ ├── userStatus.ts # 用户状态枚举
|
||||
│ ├── orderStatus.ts # 订单状态枚举
|
||||
│ └── index.ts # 统一导出所有枚举
|
||||
│
|
||||
├── shared/ # 共享类型
|
||||
│ ├── error.ts # 错误处理类型
|
||||
│ ├── pagination.ts # 分页类型
|
||||
│ └── index.ts # 统一导出所有共享类型
|
||||
│
|
||||
└── index.ts # 统一导出所有类型模块
|
||||
```
|
||||
|
||||
### 优点：
|
||||
|
||||
* **模块化管理**：每个子模块（如 `api`、`domain`、`dto`、`enums`、`shared`）管理自己的领域，清晰、简洁。
|
||||
* **可扩展性**：随着业务的增长，类型模块可以继续扩展（比如新增更多的领域模型、DTO 等），不影响其他部分的结构。
|
||||
* **统一导出**：`index.ts` 文件可以确保前后端都通过统一的方式导入所需的类型，避免混乱。
|
||||
|
||||
### 结构解释：
|
||||
|
||||
* **api/**：存放与后端接口相关的类型，专注于 API 请求和响应的结构。
|
||||
* **domain/**：存放与核心业务模型相关的类型（如用户、订单等），这些是与业务逻辑密切相关的核心对象。
|
||||
* **dto/**：存放数据传输对象（DTO），用于在后端与前端或不同服务之间传递数据时的类型约定。
|
||||
* **enums/**：存放枚举类型，通常是一些固定值的集合，比如订单状态、用户角色等。
|
||||
* **shared/**：存放前后端共享的类型，适用于所有模块的通用数据结构或工具类型。
|
||||
|
||||
---
|
||||
|
||||
## 2. **`index.ts` 统一导出**
|
||||
|
||||
`index.ts` 的设计确保了不同模块类型的统一管理和暴露，可以让你方便地通过一个入口导出整个类型库。举个例子：
|
||||
|
||||
### 2.1 **模块内的 `index.ts` 示例**
|
||||
|
||||
在每个目录下（如 `api/index.ts`）统一导出该模块的类型：
|
||||
|
||||
```typescript
|
||||
// server/src/shared/types/api/index.ts
|
||||
export * from './user';
|
||||
export * from './order';
|
||||
```
|
||||
|
||||
### 2.2 **顶层 `index.ts` 示例**
|
||||
|
||||
在 `server/src/shared/types/index.ts` 中统一导出所有子模块的类型：
|
||||
|
||||
```typescript
|
||||
// server/src/shared/types/index.ts
|
||||
export * from './api';
|
||||
export * from './domain';
|
||||
export * from './dto';
|
||||
export * from './enums';
|
||||
export * from './shared';
|
||||
```
|
||||
|
||||
这样，在需要使用类型的地方，你只需要：
|
||||
|
||||
```typescript
|
||||
// 在前后端代码中引入共享的类型
|
||||
import { User, Order } from 'shared/types'; // 通过统一入口导入所有类型
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. **最佳实践**
|
||||
|
||||
### 3.1 **类型命名规范**
|
||||
|
||||
* **模块内命名**：根据模块的职责命名文件。例如，`user.ts`、`order.ts`、`createUser.ts` 等，保持一致的命名规范。
|
||||
* **类型命名规则**：
|
||||
|
||||
* `User`（领域模型）
|
||||
* `CreateUserDTO`（DTO）
|
||||
* `UserStatusEnum`（枚举类型）
|
||||
* `UserApiResponse`（API 响应类型）
|
||||
|
||||
### 3.2 **避免重复定义**
|
||||
|
||||
* 通过 `shared` 模块存放通用的类型或工具函数，避免不同模块重复定义相同的类型。
|
||||
* **推导类型**：利用 TypeScript 的类型推导功能，减少手动重复定义。例如，从接口返回的数据中自动推导类型。
|
||||
|
||||
### 3.3 **类型检查与自动化**
|
||||
|
||||
在你的开发流程中，集成类型检查（如使用 `tsc` 或 `eslint`），确保类型的一致性和正确性：
|
||||
|
||||
* **Prettier + ESLint**：配置自动格式化和静态检查，确保代码规范一致。
|
||||
* **CI 流程**：将类型检查集成到 CI 流程中，确保每次提交都通过类型校验，避免破坏现有类型定义。
|
||||
|
||||
---
|
||||
|
||||
## 4. **AI 自动修复与生成的应用**
|
||||
|
||||
### 4.1 **AI 辅助生成和修复**
|
||||
|
||||
为了使 AI 在生产代码时无缝解决类型问题，AI 可以根据当前的代码上下文自动推导类型和生成接口。例如：
|
||||
|
||||
* **API 接口自动生成类型**：AI 可以根据接口文档自动生成请求和响应的类型。
|
||||
* **根据数据库模式自动生成模型类型**：AI 可以读取数据库表结构，自动推导出领域模型类型。
|
||||
|
||||
### 4.2 **智能类型修复**
|
||||
|
||||
* **自动类型修复**：当 AI 生成代码时，如果发现类型不匹配（例如，API 类型与前端类型不一致），AI 可以自动进行修复。
|
||||
|
||||
---
|
||||
|
||||
## 5. **总结**
|
||||
|
||||
你设计的结构非常合理，**清晰模块化**并且**通过 `index.ts` 实现统一导出**，便于管理和扩展。为了确保类型的一致性和高效开发，推荐以下几点：
|
||||
|
||||
* **模块化管理**：将不同领域的类型分开管理，保持清晰和可扩展性。
|
||||
* **统一导出**：通过 `index.ts` 统一暴露类型，便于前后端团队共享和引用。
|
||||
* **智能推导与自动修复**：利用 AI 等工具，根据上下文推导类型，自动生成和修复类型问题。
|
||||
|
||||
这种结构将大大提高你在开发过程中管理类型的效率，并且**随着项目的扩展，可以轻松地加入更多功能模块**，保持代码的清晰和规范。
|
||||
Reference in New Issue
Block a user