Forráskód Böngészése

Merge branch 'master' of e.coding.net:g-ueau9359/kku/kku_laravel

dongasai 7 hónapja
szülő
commit
64cdd93bc6

+ 188 - 0
AiWork/2025年06月/16日2101-完善Test模块README文档.md

@@ -0,0 +1,188 @@
+# 完善Test模块README文档
+
+**任务时间**: 2025年06月16日 21:01  
+**任务类型**: 文档完善  
+**模块**: Test  
+**状态**: ✅ 已完成
+
+## 任务概述
+
+基于物品模块、Mex模块、农场模块的架构设计和最佳实践,全面完善Test模块的README.md文档,使其成为新模块开发的标准参考模板。
+
+## 执行过程
+
+### 1. 信息收集阶段
+
+#### 1.1 加载记忆习惯
+- 获取当前时间:2025年06月16日 21:01:29 CST
+- 加载用户偏好和开发规范
+- 了解项目架构设计原则
+
+#### 1.2 模块调研
+通过codebase-retrieval工具深入研究了三个核心模块:
+
+**GameItems模块(物品模块)**:
+- 完整的物品生命周期管理
+- 物品冻结功能的拆堆模式设计
+- 统一属性和单独属性物品的处理机制
+- 宝箱系统、合成系统、分解系统
+- 15个数据模型,完整的服务层和逻辑层
+- 事件系统和后台管理功能
+
+**Mex模块(农贸市场交易系统)**:
+- 基于系统仓库的撮合交易机制
+- 价格优先、时间优先的撮合算法
+- 多币种适配功能
+- 订单状态管理和事务处理
+- 5个核心数据表,完整的枚举定义
+- 分离的买入/卖出撮合任务
+
+**Farm模块(农场模块)**:
+- 土地、房屋、种子、作物的完整管理体系
+- 生长周期和灾害系统
+- 神灵加持系统
+- 15个数据模型,复杂的业务逻辑
+- 与其他模块的深度集成
+
+### 2. 文档设计阶段
+
+#### 2.1 结构规划
+基于三个模块的共同特点,设计了标准的文档结构:
+1. 模块概述 - 功能定位和特点
+2. 目录结构 - 完整的目录树和说明
+3. 架构设计 - 分层架构和设计原则
+4. 开发规范 - 命名规范和代码规范
+5. 最佳实践 - 数据库设计、事件系统、后台管理
+6. 参考示例 - 三个模块的设计亮点
+
+#### 2.2 内容提炼
+从三个模块中提炼出最佳实践:
+- **命名规范**:统一的类命名、数据库命名、命名空间规范
+- **架构设计**:分层架构、单一职责、依赖注入原则
+- **代码示例**:模型、服务、枚举、验证的标准写法
+- **数据库设计**:表结构设计和索引设计原则
+- **事件系统**:事件定义和监听器的标准模式
+
+### 3. 文档编写阶段
+
+#### 3.1 完整目录结构
+设计了包含所有必要目录的完整结构:
+- AdminControllers/ - 后台管理(含Helper、Actions子目录)
+- Commands/ - 命令行工具
+- Config/ - 配置文件
+- Databases/ - 数据库相关(含GenerateSql、Repositories)
+- Docs/ - 文档目录
+- Dtos/ - 数据传输对象
+- Enums/ - 枚举定义
+- Events/ - 事件类
+- Exceptions/ - 自定义异常
+- Listeners/ - 事件监听器
+- Logics/ - 业务逻辑
+- Models/ - 数据模型
+- Providers/ - 服务提供者
+- Services/ - 服务接口
+- Validations/ - 验证类
+- Validators/ - 验证器
+- Tests/ - 测试文件
+
+#### 3.2 代码示例
+提供了完整的代码示例:
+- 模型类:继承UCore\ModelCore,包含field注释块
+- 服务类:静态方法,调用Logic层
+- 枚举类:使用PHP enum语法,避免魔法数字
+- 验证类:Validation和Validator的标准写法
+- 控制器:后台管理的标准实现
+- 事件系统:事件和监听器的定义
+
+#### 3.3 最佳实践
+总结了数据库设计、事件系统、后台管理的最佳实践:
+- 数据库表结构设计原则
+- 索引设计策略
+- 事件驱动的模块间通信
+- 后台管理的标准实现
+- 测试规范和手动测试
+
+## 实现成果
+
+### 1. 文档结构完善
+- 从原来的30行简单说明扩展到587行详细文档
+- 包含7个主要章节,内容全面系统
+- 提供了完整的开发指南和参考示例
+
+### 2. 标准模板建立
+- 建立了新模块开发的标准模板
+- 提供了完整的目录结构参考
+- 包含了所有必要的代码示例
+
+### 3. 最佳实践总结
+- 总结了三个核心模块的设计精华
+- 提炼了通用的开发规范和设计原则
+- 为团队开发提供了统一的标准
+
+### 4. 参考价值提升
+- 物品模块:冻结功能、拆堆模式、事务处理
+- Mex模块:撮合算法、状态机、定时任务
+- 农场模块:生长周期、灾害系统、升级机制
+
+## 技术亮点
+
+### 1. 架构设计
+- 清晰的分层架构:Controllers → Services → Logics → Models
+- 明确的职责分离:服务层对外,逻辑层内部
+- 标准的模块交互:事件通信、服务调用
+
+### 2. 开发规范
+- 统一的命名规范:类名、表名、命名空间
+- 标准的代码结构:模型、服务、枚举、验证
+- 完整的验证机制:Validation + Validator
+
+### 3. 最佳实践
+- 数据库设计:表结构、索引、约束
+- 事件系统:松耦合的模块间通信
+- 后台管理:标准的CRUD操作
+
+## 文档价值
+
+### 1. 新手指导
+- 提供了完整的模块开发入门指南
+- 包含了详细的代码示例和说明
+- 降低了新模块开发的学习成本
+
+### 2. 标准参考
+- 建立了统一的开发标准和规范
+- 提供了可复用的代码模板
+- 确保了代码质量的一致性
+
+### 3. 经验传承
+- 总结了成熟模块的设计经验
+- 提炼了通用的设计模式和最佳实践
+- 为团队知识积累提供了载体
+
+## 后续建议
+
+### 1. 模板应用
+- 在新模块开发中应用此模板
+- 根据实际使用情况持续优化
+- 收集开发者反馈完善文档
+
+### 2. 文档维护
+- 定期更新文档内容
+- 补充新的最佳实践
+- 保持与项目架构的同步
+
+### 3. 培训推广
+- 组织团队学习和讨论
+- 建立代码审查标准
+- 推广最佳实践的应用
+
+## 总结
+
+本次任务成功完善了Test模块的README.md文档,将其从简单的目录说明升级为完整的开发指南。通过深入研究物品模块、Mex模块、农场模块的架构设计,提炼出了通用的开发规范和最佳实践,为新模块开发提供了标准模板和参考指南。
+
+文档内容全面系统,包含了目录结构、架构设计、开发规范、代码示例、最佳实践等各个方面,具有很高的参考价值和实用性。这将有助于提高团队开发效率,确保代码质量的一致性,促进项目的标准化发展。
+
+---
+
+**提交信息**: 完善Test模块README.md文档  
+**提交哈希**: 48aeca24  
+**分支**: master

+ 10 - 0
AiWork/WORK.md

@@ -7,6 +7,16 @@
 
 ## 已完成任务
 
+**2025-06-16 21:01** - 完善Test模块README文档 - 基于物品模块、Mex模块、农场模块的架构设计完善Test模块文档
+- 任务:基于物品模块、Mex模块、农场模块的架构设计和最佳实践,全面完善Test模块的README.md文档
+- 调研:深入研究GameItems模块(物品冻结功能、拆堆模式)、Mex模块(撮合交易、多币种适配)、Farm模块(生长周期、灾害系统)
+- 结构:设计7个主要章节的完整文档结构,从30行扩展到587行详细文档
+- 内容:完整目录结构、架构设计、开发规范、命名规范、代码示例、最佳实践、参考示例、开发指南
+- 规范:统一的类命名、数据库命名、命名空间规范,标准的模型、服务、枚举、验证写法
+- 实践:数据库设计原则、事件系统、后台管理、测试规范的最佳实践总结
+- 价值:建立新模块开发的标准模板,提供完整的开发指南和参考,降低学习成本,确保代码质量一致性
+- 文件:./AiWork/2025年06月/16日2101-完善Test模块README文档.md
+
 **2025-06-16 16:19** - 修复用户登录后资金账户未创建问题 - 创建Fund模块登录成功事件监听器自动创建资金账户
 - 问题:用户登录后,资金账户未创建,比如:userid 38936,在kku_fund表中没有对应的资金账户记录
 - 分析:Fund模块提供了AccountService::check4user()方法,但没有在登录成功事件中调用此方法

+ 202 - 0
AiWork/偏好习惯.md

@@ -0,0 +1,202 @@
+# 偏好习惯
+
+## 语言和文档偏好
+
+### 语言使用
+- 使用中文进行交流和编写文档,代码中增加中文注释
+
+### 文档规范
+- Model类添加field start/end注释块,只保留// attrlist start/end标识符包围的$fillable定义
+- 自动生成目录下添加README.md声明内容自动生成不可修改
+- README.md使用可点击目录结构,包含锚点链接和状态图标
+- 文档使用明确关键词:'买入'改为'用户买入物品','卖出'改为'用户卖出物品'
+- 基于成熟模块架构设计完善文档,提炼通用开发规范和最佳实践
+
+### 任务管理
+- 任务开始前/后检查`git status`,提交代码并Push,使用中文CommitMessage
+- 任务完成后创建记录于'./AiWork/年月/'目录,文件名'日时分-任务标题.md',更新WORK.md
+- 模块开发完成情况全面检查:服务层、逻辑层、模型层、接口层、事件系统、后台管理、验证系统
+- 清理模块残留时全面检查:代码文件、数据库表、文档内容
+
+## 代码结构和命名规范
+
+### 命名空间和前缀
+- Handler命名空间:'App\Module\AppGame\Handler'
+- 数据库表前缀:全局'kku_',物品模块'item_',宠物模块'pet_'
+
+### 类命名规范
+- 枚举:遵循PSR-4标准,使用PHP enum语法,避免魔法数字
+- 控制器和仓库:名称与关联表名匹配
+- Validator类:以'Validator'结尾
+- Repository类:以'Repository'结尾
+
+### 设计原则
+- 功能拆分为独立简单静态类,避免复杂设计模式
+
+## 架构设计偏好
+
+### 模型层设计
+- 继承自\UCore\ModelCore,保持无业务逻辑
+- 不设置$prefix属性(全局配置在config/database.php)
+- 在模型中定义访问器而非控制器中实现逻辑
+- 为模型创建独立Cast类,不同模型不共用Cast类
+- 不使用数据库迁移类,直接提供SQL语句修改数据库结构
+
+### 控制器和仓库层
+- 后端控制器继承自UCore\DcatAdmin\AdminController
+- 使用Grid/Show/Form的'make'方法实例化
+- 使用GridHelper/ShowHelper/FormHelper/FilterHelper辅助类
+- Repository类参考Fund模块实现,内部不包含方法,仅供后台管理数据访问
+- 后台控制器添加路由注释,加入后台菜单适当位置
+- 后台列表页面来源表名列可点击跳转到对应详情页面
+
+### 服务层和逻辑层
+- 服务层:对外Service(静态方法),内部Logic类
+- 服务层直接使用逻辑层和模型,仓库层仅供后台控制器使用
+- 模块间通过Service层交互,不直接访问其他模块模型
+- 服务层返回DTO对象而非Model,Handler中将DTO转换为protobuf格式
+- 逻辑层不能开启事务
+- DTO类继承自UCore\Dto\BaseDto,实现fromModel静态方法,使用驼峰命名公共属性
+
+### 验证机制
+- 使用Validation和Validator类处理验证逻辑,参考GodActivationValidation模式
+- Validator类实现单一验证逻辑,使用addError方法而非throwMessage
+- Validator类字段Key使用$arg参数传入,不直接硬编码
+- Validation类禁止动态属性赋值,需先定义属性并声明类型
+
+### Handler和模块设计
+- Handler类参考PesticideHandler模式:先验证再执行操作
+- Handler类不设置异常处理,继续抛出异常交由框架处理
+- Handler成功时使用RESPONSE_CODE常量设置响应码,不使用魔法数字0
+- 事件用于模块间通信,模块内部不使用事件机制
+- 动作型方法使用Res对象处理返回值,不直接返回数组
+
+## 游戏系统功能偏好
+
+### 奖励系统
+- 实现消耗组、条件组和奖励组功能,支持多种类型配置和验证
+- 奖励组系统支持复杂随机奖励机制:概率获得、必中获得、倍率功能
+- 奖励组/消耗组/条件组增加标签功能,三个组共用标签数据库表,用于后台查询筛选
+
+### 皮肤系统
+- 使用单表设计:game模块创建game_user_skins表
+- 一个字段表示当前使用皮肤,一个字段表示持有皮肤
+
+## 核心模块设计偏好
+
+### Fund模块(资金系统)
+- 全面采用小数存储模式:DECIMAL(30,10)直接存储小数值
+- 精度配置硬编码到FUND_CURRENCY_TYPE枚举中
+- 支持冻结账户功能,钻石币种支持10位小数精度
+- '币种ID'指FUND_CURRENCY_TYPE枚举value值(1=金币,2=钻石,3=人民币,4=美元)
+- Point模块基于Fund模块创建,专注整数型积分逻辑,不使用小数模式
+
+### Mex模块(农贸市场交易系统)
+#### 账户体系
+- 仓库账户USER_ID=15:用户卖出时资金从仓库转出到用户、物品转入仓库;用户买入时资金从仓库转入用户、物品从仓库转出到用户
+- 调控账户USER_ID=16:用于市场调控操作,确保总量不变
+
+#### 交易机制
+- 挂单时无价格验证,最低价和最高价仅为参考
+- 挂单不会立即成交,所有订单先创建后由撮合任务处理成交
+- 价格验证仅在撮合成交时进行
+- 挂单操作没有价格限制(重要业务规则)
+
+#### 撮合算法
+- 大额订单应该卡住小额订单(业务需求而非要避免的问题)
+- 系统总量守恒验证不可用(交易期间会产生新的物品和资金)
+- 买入/卖出分为两个独立任务处理,流程图分开设计
+
+#### 多币种适配
+- 默认币种为钻石,通过FundLogic类管理币种与账户类型映射关系
+- 订单表和成交记录表增加currency_type字段
+- MexOrderValidator根据币种动态选择账户类型
+- 不再自行处理Fund模块数值精度,信任Fund模块数据
+- 数额验证直接使用Fund模块FundService进行比较
+
+#### 资金物品流向
+- 买入:资金从用户可用→冻结→仓库,物品从仓库→用户
+- 卖出:物品从用户可用→冻结→仓库,挂单操作只在用户内部转移
+
+### GameItem模块(物品系统)
+#### 物品冻结功能
+- 用于匹配交易过程中卖出物品时的状态管理
+- 冻结功能设计原则:
+  - 交易日志不记录冻结信息(冻结不改变归属)
+  - 冻结采用拆堆模式(1000个堆叠冻结200个则拆分为200个冻结堆+800个可用堆)
+  - ItemUser表增加is_frozen字段标识冻结状态
+  - 冻结记录表使用source_id和source_type而非order_id
+  - 不需要自动解冻逻辑(由冻结发起方处理)
+  - ItemUser表只需frozen_log_id字段关联冻结日志
+  - 不需要冻结数量、原因、时间、过期时间等冗余字段
+- ItemInstance表是物品实例表,记录物品信息而不存在物品归属概念,不应添加冻结相关字段
+
+#### Protobuf适配
+- DataItem已更新,堆id对应item_user表的id
+- 设置堆id(iu_id)字段为item_user表的id
+- 更新DataHandler、QueryHandler、AppGameProtobufResponseListener、LastDataHelper和ItemUserDto
+- 确保所有物品数据传输包含完整的堆叠标识和冻结状态信息
+
+## 调试和测试偏好
+
+### 调试工具
+- 任务开始前获取时间,使用'date'命令
+- 使用mcp测试网页修改和执行sql
+- 使用`php artisan debug:reproduce-error`命令回放错误请求进行调试验证
+
+### 错误处理
+- 接口数据问题时优先检查数据结构字段名匹配
+- 注意Logic层返回字段名与Handler中访问字段名一致
+- Handler处理protobuf响应时确保所有必需字段有正确数据源
+
+### 测试规范
+- 在tests目录编写非模块phpunit测试
+- 使用vendor/bin/phpunit运行测试
+- 不使用laravel console组织测试
+
+## 项目环境和特殊模块偏好
+
+### 项目环境
+- 使用Docker运行,访问地址:http://kku_laravel.local.gd
+
+### Cleanup模块(数据清理系统)
+- 创建专门的Cleanup模块实现数据清理功能,不在game模块中创建清理命令
+- 设计为独立数据清理系统,提供后台管理界面配置每个表的清理条件
+- 包含完整安全机制:多重确认、预览模式、权限控制、操作审计、分批处理
+- 支持完全自由的表选择,不局限于模块边界
+- 5种表选择方式:自定义、模块、分类、全量、混合选择
+- 不同清理方式:清空表、删除所有、按时间删除、按用户删除、按条件删除
+- 表级别独立配置:清理类型、条件、优先级、备份设置、说明备注
+### ThirdParty模块(第三方服务对接)
+- 专门处理接入第三方服务需求,与OpenAPI模块互补(OpenAPI提供API给别人,ThirdParty使用别人的API)
+- 实现标准化基础架构:BaseRequest请求基类、BaseWebhook基类、WebhookDispatchService分发服务
+- 路由规则:/thirdParty/webhook/{包名}/{Handler路由}
+- 支持ThirdParty命名空间下的包管理,自动处理配置读取、配额检查、日志记录、错误处理
+- Request机制规范:一个Request类只完成一种请求,遵循单一职责原则
+- WebhookHandler只处理一种请求类型,webhook只支持POST请求
+- Webhook签名验证应在接收器实例化之前进行
+- 后台管理菜单结构:外接管理作为一级菜单,下设OpenApi模块和ThirdParty模块作为二级菜单
+- 完全符合dcat admin设计规范:使用Content/Row/Column布局系统,创建ServiceOverviewCard统计卡片
+- 设计完整三方登录方案:基于OAuth2.0统一架构,支持微信、QQ、支付宝、微博等主流平台
+
+### UrsPromotion模块(URS推广系统)
+- 专门为URS业务场景设计的推广系统,与Promotion模块完全独立
+- 使用独立命名空间App\Module\UrsPromotion和数据库表前缀urs_promotion_
+- 三代推广系统:支持直推、间推、三推三代推广关系
+- 两种收益类型:推广收益(下级进入农场)和种植收益(下级收获作物)
+- 6个达人等级(非达人到顶级达人),不同等级享有不同收益分成比例
+- 分离映射关系设计:独立用户映射表 + 纯URS推荐关系表
+- 推荐关系只存储urs_user_id,通过映射表关联农场用户
+- 奖励分发逻辑:检查用户映射关系,未进入农场的用户跳过
+- 已移除推荐码功能,直接通过URS用户ID建立关系
+- 数据库升级到v3版本:字段名统一(user_id->urs_user_id),新增farm_user_id冗余字段
+
+### OpenAPI模块(API开放平台)
+- 扩展钻石充值/提取功能,每个开发者应用分配专用账户
+- 充值账户=100000+应用ID,提取账户=200000+应用ID
+- 钻石操作使用FUND_TYPE::FUND2类型,支持10位小数精度
+- 包含完整的验证、事务处理和操作日志记录机制
+
+### 系统模块概况
+- 系统包含35个模块
+- Promotionurs模块已被移除,创建新的UrsPromotion模块替代

+ 0 - 166
AiWork/记忆习惯.md

@@ -1,166 +0,0 @@
-# 记忆习惯
-
-## 语言和文档偏好
-
-- 用户偏好使用中文进行交流和编写文档,在代码中增加中文注释
-- 用户希望在Model类中添加field start/end注释块,并只保留被// attrlist start/end标识符包围的$fillable定义
-- 用户希望在自动生成的目录下添加README.md文件,声明该目录内容是自动生成的不能修改
-- 用户希望在任务开始前/后检查`git status`,提交代码并Push,使用中文编写CommitMessage
-- 用户希望在任务完成后,将任务记录创建于'./AiWork/年月/'目录,文件名'日时分-任务标题.md',更新WORK.md文件
-- 用户偏好在文档中使用明确的关键词:'买入'应改为'用户买入物品','卖出'应改为'用户卖出物品',以避免概念混淆
-- 用户偏好在README.md文档中使用可点击的目录结构,包含锚点链接和状态图标,便于快速导航到指定模块章节
-- 用户要求对模块开发完成情况进行全面检查,包括服务层、逻辑层、模型层、接口层、事件系统、后台管理、验证系统等所有组件的完整性验证
-- 用户要求在清理模块残留时进行全面检查,包括代码文件、数据库表、文档内容,确保清理彻底
-
-## 代码结构和命名规范
-
-- 用户偏好handler命名空间为'App\Module\AppGame\Handler'
-- 用户偏好表名前缀:物品模块'item_',宠物模块'pet_',所有数据库表有'kku_'前缀
-- 用户偏好enum文件遵循PSR-4命名标准,避免使用魔法数字,并且使用PHP enum语法而不是class+const方式定义枚举
-- 用户偏好controller和repository名称与关联的表名匹配
-- 用户偏好Validator类名以'Validator'结尾,Repository类以'Repository'结尾
-- 用户偏好将功能拆分为独立的简单静态类,避免复杂的设计模式
-
-## 模型和数据访问设计
-
-- 模型应继承自\UCore\ModelCore,保持无业务逻辑,使用单独的Validator类进行验证
-- 模型中不需要设置$prefix属性,因为表前缀已在config/database.php中全局配置
-- 用户希望在模型中定义访问器而不是在控制器中实现逻辑
-- 用户要求为模型创建独立的Cast类,不同模型不应共用同一个Cast类
-- 用户不使用数据库迁移类,需要直接提供SQL语句来修改数据库结构
-- 模型中不应存在业务逻辑需要移除
-
-## 控制器和仓库实现规范
-
-- 后端控制器应继承自UCore\DcatAdmin\AdminController
-- 用户偏好使用Grid/Show/Form的'make'方法进行实例化
-- 用户偏好使用GridHelper/ShowHelper/FormHelper/FilterHelper
-- Repository类应该参考Fund模块的Repository实现,其内不应包含任何方法,只用于后台管理数据访问
-- 用户偏好后台控制器需要添加路由注释,并将路由加入后台菜单的适当位置
-- 用户偏好在后台列表页面中,来源表名列应该可点击并跳转到对应来源的详情页面
-
-## 服务层和逻辑层设计
-
-- 服务层分为对外的Service(静态方法)和内部的Logic类
-- 服务层应直接使用逻辑层和模型,而仓库层仅供后台控制器使用
-- 模块间应通过Service层进行交互,不应直接访问其他模块的模型
-- 服务层应返回DTO对象而非直接返回Model,在Handler中将DTO转换为protobuf格式
-- 逻辑层(Logic层)中不能开启事务,需要检查并修复逻辑层中的事务开启代码
-- DTO类应继承自UCore\Dto\BaseDto,实现fromModel静态方法,使用驼峰命名的公共属性,放置在模块的Dtos目录下
-
-## 验证机制
-
-- 用户偏好使用Validation和Validator类进行验证逻辑处理,参考GodActivationValidation的模式
-- Validator类应实现单一验证逻辑,使用addError方法而非throwMessage进行错误处理
-- Validator类中的字段Key应使用$arg参数传入,而不是直接硬编码
-- Validation类使用规范:禁止动态属性赋值,需要先定义属性并声明类型
-
-## Handler和模块设计
-
-- Handler类应参考PesticideHandler模式:先验证再执行操作,创建必要的Validation和Validator类
-- Handler类中不应该设置异常处理,应该继续抛出异常交由框架处理
-- 用户偏好在Handler成功时使用RESPONSE_CODE常量设置响应码,而不是使用魔法数字0
-- 事件用于模块间通信,模块内部不应使用事件机制,模块的事件注册和监听应在模块内实现
-- 用户偏好在动作型方法中使用Res对象处理返回值,而不是直接返回数组
-
-## 游戏系统功能
-
-- 用户希望实现消耗组、条件组和奖励组功能,支持多种类型的配置和验证
-- 奖励组系统支持复杂的随机奖励机制,包括概率获得和必中获得,并支持倍率功能
-- 用户要求为奖励组/消耗组/条件组增加标签功能,三个组共用一个标签数据库表,标签用于后台查询筛选
-- 用户偏好皮肤系统使用单表设计:game模块中创建game_user_skins表,用一个字段表示当前使用皮肤,一个字段表示持有的皮肤
-
-## 模块特定设计
-
-### Fund模块
-- Fund模块全面采用小数存储模式,数据库使用DECIMAL(30,10)直接存储小数值,不再使用整数存储转换
-- Fund模块精度配置硬编码到FUND_CURRENCY_TYPE枚举中,用于显示格式化和精度验证
-- Fund模块需要支持冻结账户功能,钻石币种支持10位小数精度,冻结账户作为特殊账户类型与普通账户同属一个币种
-- Fund模块中'币种ID'概念明确指FUND_CURRENCY_TYPE枚举的value值(1=金币,2=钻石,3=人民币,4=美元),而不是fund_currency数据库表的自增ID字段
-- Point模块基于Fund模块创建,专注于整数型积分逻辑处理,不使用小数模式
-
-### Mex模块
-- Mex模块业务规则:仓库账户USER_ID为15,用户卖出时资金从仓库转出到用户、物品转入仓库,用户买入时资金从仓库转入用户、物品从仓库转出到用户,调控账户USER_ID为16用于市场调控操作,确保总量不变
-- Mex模块资金物品流向规则:买入时资金从用户可用→冻结→仓库,物品从仓库→用户;卖出时物品从用户可用→冻结→仓库,挂单操作只在用户内部转移不改变总量
-- Mex模块交易机制:挂单时无价格验证,最低价和最高价仅为参考,挂单不会立即成交,所有订单先创建后由撮合任务处理成交,价格验证仅在撮合成交时进行
-- Mex模块挂单操作没有价格限制,这是重要的业务规则
-- Mex模块撮合算法设计原则:大额订单应该卡住小额订单,这是业务需求而非要避免的问题
-- Mex模块中系统总量守恒验证不可用,因为交易期间会产生新的物品和资金,总量会发生变化
-- Mex模块的买入/卖出应该分为两个独立的任务处理,流程图也需要分开设计
-- Mex模块需要支持多币种适配功能,默认币种为钻石,通过FundLogic类管理币种与账户类型的映射关系
-- Mex模块多币种适配:订单表和成交记录表增加currency_type字段,FundLogic提供币种映射,MexAccountLogic支持币种参数传递
-- Mex模块AddHandler资金验证已修正支持多币种:MexOrderValidator根据币种动态选择账户类型,MatchexchangeAddValidation自动添加默认币种信息,确保资金验证使用正确的币种和精度
-- Mex模块不再自行处理Fund模块的数值精度,移除了number_format和bcpow等精度处理代码,改为信任Fund模块的数据,数额验证直接使用Fund模块的FundService进行比较
-- RequestMatchexchangeOpen接口已完成对接:创建OpenHandler获取开放交易物品列表,调用MexPriceConfigService获取启用配置,返回物品ID数组,路由配置已存在可直接使用
-
-### GameItem模块
-- GameItem模块需要实现物品冻结功能,用于匹配交易过程中卖出物品时的状态管理
-- GameItem模块冻结功能设计原则:交易日志不记录冻结信息(冻结不改变归属),冻结采用拆堆模式(如1000个堆叠冻结200个则拆分为200个冻结堆+800个可用堆),ItemUser表增加is_frozen字段标识冻结状态,冻结记录表使用source_id和source_type而非order_id,不需要自动解冻逻辑(由冻结发起方处理),ItemUser表只需frozen_log_id字段关联冻结日志,不需要冻结数量、原因、时间、过期时间等冗余字段
-- ItemInstance表是物品实例表,记录物品信息而不存在物品归属概念,因此不应该在ItemInstance表中添加冻结相关字段
-
-### Protobuf适配
-- Protobuf的DataItem已更新,堆id现在对应item_user表的id,需要适配DataHandler查询和Lastdata数据同步
-- 完成了Protobuf DataItem适配工作,设置堆id(iu_id)字段为item_user表的id,更新了DataHandler、QueryHandler、AppGameProtobufResponseListener、LastDataHelper和ItemUserDto,确保所有物品数据传输包含完整的堆叠标识和冻结状态信息
-
-## 调试和错误处理
-
-- 任务开始前获取时间,使用'date'命令
-- 使用mcp测试网页的修改
-- 使用mcp执行sql
-- 当遇到接口数据问题时,优先检查数据结构字段名是否匹配,特别注意Logic层返回的字段名与Handler中访问的字段名要一致
-- 在Handler中处理protobuf响应时,确保所有必需字段都有正确的数据源,特别是user_id等关键字段
-- 使用`php artisan debug:reproduce-error`命令回放错误请求进行调试验证
-
-## 测试
-- 在tests目录编写非模块phpunit测试
-- 使用vendor/bin/phpunit来运行
-- 不使用laravel 的 console来组织测试
-
-## 项目相关运行和访问
-- 项目已经使用Docker运行,访问地址:http://kku_laravel.local.gd
-- 用户偏好创建专门的Cleanup模块来实现数据清理功能,而不是在game模块中创建清理命令
-- Cleanup模块设计为独立的数据清理系统,提供后台管理界面配置每个表的清理条件,支持测试数据清理
-- Cleanup模块包含完整的安全机制:多重确认、预览模式、权限控制、操作审计、分批处理等
-- Cleanup模块支持完全自由的表选择,不局限于模块边界,可以自由配置清理任意表
-- 支持5种表选择方式:自定义、模块、分类、全量、混合选择,提供最大的灵活性
-- 每个表都可以制定不同的清理方式:清空表、删除所有、按时间删除、按用户删除、按条件删除
-- 支持表级别的独立配置:清理类型、条件、优先级、备份设置、说明备注等
-- 用户已创建ThirdParty模块,专门处理接入第三方服务的需求,与OpenAPI模块互补(OpenAPI提供API给别人,ThirdParty使用别人的API)
-- 系统包含35个模块,Promotionurs模块已被移除,创建了新的UrsPromotion模块来替代
-- UrsPromotion模块是专门为URS业务场景设计的推广系统,与Promotion模块完全独立
-- UrsPromotion模块使用独立的命名空间App\Module\UrsPromotion和数据库表前缀urs_promotion_
-- UrsPromotion模块包含完整的目录结构、文档体系和数据库设计,支持URS专用的达人等级和收益分成机制
-- UrsPromotion模块已升级为三代推广系统:支持直推、间推、三推三代推广关系,新增推广收益和种植收益两种类型
-- UrsPromotion模块完整实现:枚举类型、模型层、逻辑层、服务层、仓库层、测试命令,数据库表创建和初始化数据完成
-- UrsPromotion模块达人等级配置:6个等级(非达人到顶级达人),不同等级享有不同的推广收益和种植收益分成比例
-- UrsPromotion模块收益分成机制:推广收益(下级进入农场)和种植收益(下级收获作物),根据达人等级和推荐层级确定分成比例
-- UrsPromotion模块已移除推荐码功能,实现分离映射关系设计:独立的用户映射表 + 纯URS推荐关系表
-- UrsPromotion模块分离映射关系设计:推荐关系只存储urs_user_id,通过映射表关联农场用户
-- UrsPromotion模块奖励分发逻辑:检查用户映射关系,未进入农场的用户跳过,继续处理上级用户
-- UrsPromotion模块数据库已升级到v3版本:完成字段名统一(user_id->urs_user_id),修复模型关系定义,新增farm_user_id冗余字段
-- UrsPromotion模块已完全移除推荐码功能:删除推荐码表和字段,简化推荐关系建立流程,直接通过URS用户ID建立关系
-- UrsPromotion模块已补充用户绑定关系后台管理页面:创建UrsUserMappingController,支持只读模式的列表、详情、筛选功能
-- UrsPromotion模块用户绑定关系后台管理功能已修复:在UrsUserMappingService中添加validateMapping()和syncUserInfo()方法,修复"同步信息"和"验证映射"按钮报错问题
-- UrsPromotion模块达人等级逻辑已创建专门文档:详细说明6级达人体系、升级条件、收益分成机制、核心服务和业务流程
-- OpenAPI模块已扩展钻石充值/提取功能,每个开发者应用分配专用账户:充值账户=100000+应用ID,提取账户=200000+应用ID
-- OpenAPI模块钻石操作使用FUND_TYPE::FUND2类型,支持10位小数精度,包含完整的验证、事务处理和操作日志记录机制
-- ThirdParty模块已实现标准化基础架构:BaseRequest请求基类、BaseWebhook基类、WebhookDispatchService分发服务、路由规则/thirdParty/webhook/{包名}/{Handler路由}
-- ThirdParty模块支持ThirdParty命名空间下的包管理,自动处理配置读取、配额检查、日志记录、错误处理
-- ThirdParty模块提供完整的URS包示例和详细的使用文档,包含基础架构测试命令验证功能
-- ThirdParty模块Request机制规范:一个Request类只完成一种请求,遵循单一职责原则,避免使用switch语句处理多种操作
-- ThirdParty模块设计规范:一个WebhookHandler只处理一种请求类型,webhook只支持POST请求
-- 用户偏好Webhook签名验证应在接收器实例化之前进行,service查询时应增加提供config对象
-- 用户偏好后台管理菜单结构:外接管理作为一级菜单,下设OpenApi模块和ThirdParty模块作为二级菜单
-- ThirdParty模块已设计完整的三方登录方案:基于OAuth2.0统一架构,支持微信、QQ、支付宝、微博等主流平台
-- 三方登录方案包含完整的数据库设计、枚举定义、模型设计、服务层、平台适配器、API接口、安全考虑和监控方案
-- 三方登录方案与现有SessionApp和User模块完美集成,支持自动注册、账号绑定解绑、登录状态管理等功能
-- ThirdParty模块路由注册和视图使用已修复:删除传统路由文件,统一使用#[Resource]注解注册,移除所有自定义视图,使用dcat admin标准组件构建页面
-- ThirdParty模块完全符合dcat admin设计规范:使用Content/Row/Column布局系统,创建ServiceOverviewCard统计卡片,API接口返回标准JSON格式
-- Cleanup模块开发完成75%进度:实现完整的枚举定义(7个枚举)、数据库设计(8个表)、模型层(5个模型)、服务层(主服务+表扫描器)、命令行工具(2个命令)、REST API接口、配置文件和服务提供者注册
-- Cleanup模块剩余工作:需要实现4个逻辑类CleanupPlanLogic、CleanupTaskLogic、CleanupExecutorLogic、BackupLogic来完成计划管理、任务执行、数据清理和备份功能
-- Cleanup模块支持5种清理类型(清空表、删除所有、按时间删除、按用户删除、按条件删除)和5种表选择方式(自定义、模块、分类、全量、混合)
-- Cleanup模块提供完整的命令行接口:cleanup:scan-tables扫描表生成配置,cleanup:data管理计划和任务,支持预览、执行、状态查看等操作
-- Cleanup模块包含完整的安全机制:受保护表列表、权限控制、自动备份、操作确认、详细日志记录等功能
-- Cleanup模块开发计划已按照Transfer模块DEV.md格式重构:采用9个开发阶段,详细的任务清单,进度表格,技术架构图,风险管控等标准化格式
-- Cleanup模块需要区分API接口和Dcat Admin后台:目前只完成了REST API接口,Dcat Admin后台管理界面还需要单独开发,包括Grid列表、Form表单、Show详情等页面
-- Cleanup模块不应包含:数据库迁移文件、路由注册(使用注解)、视图文件、前端资源、中间件、任务调度、普通控制器(只有AdminControllers用于Dcat Admin后台)

+ 586 - 26
app/Module/Test/README.md

@@ -1,29 +1,589 @@
 # Test 模块
 
-## 模块说明
-Test 模块是一个示例模块,用于展示模块化开发的最佳实践。
-
-## 目录结构
-```
-├── AdminControllers/    # 后台控制器
-├── Commands/            # 命令目录
-├── Config/              # 配置目录
-├── Database/            # 数据库目录
-│   └── create.sql       # 创建数据表的SQL
-└── Enums/               # 枚举(枚举的名和Case全大写)
-├── Models/              # 模型目录
-├── Providers/           # Providers
-├── Events/              # 事件目录
-├── Logic/               # Logic目录/逻辑目录
-├── Listeners/           # 监听器目录 
-├── Queues/              # 队列目录
-├── Repositorys/         # 仓库目录(后台控制器专用,其他场景不要用)
-├── Services/            # 服务目录(供其他模块使用)
-│   └──  TestService.php       # 服务之一
-├── Validations/         # Validation 目录(不是Laravel的Validation规则)
-├── Validators/          # Validator目录
-└── Tests/               # 测试目录
-```
-
-## 注意事项
+> 示例模块 - 展示模块化开发的最佳实践和标准架构
+
+## 目录
+
+1. [模块概述](#1-模块概述)
+2. [目录结构](#2-目录结构)
+3. [架构设计](#3-架构设计)
+4. [开发规范](#4-开发规范)
+5. [最佳实践](#5-最佳实践)
+6. [参考示例](#6-参考示例)
+
+## 1. 模块概述
+
+### 1.1 功能与目的
+
+Test模块是一个标准的示例模块,用于展示项目中模块化开发的最佳实践。它提供了完整的模块架构参考,包括数据层、业务逻辑层、服务层、控制器层等各个层次的标准实现方式。
+
+### 1.2 主要特点
+
+- **标准架构**:遵循项目统一的分层架构设计
+- **完整示例**:包含所有必要的目录和文件结构
+- **最佳实践**:展示代码组织、命名规范、设计模式等最佳实践
+- **参考模板**:为新模块开发提供标准模板
+
+## 2. 目录结构
+
+### 2.1 完整目录树
+
+```
+app/Module/Test/
+├── AdminControllers/           # 后台管理控制器
+│   ├── Helper/                # 控制器辅助类
+│   │   ├── TestGridHelper.php # 表格辅助类
+│   │   ├── TestFormHelper.php # 表单辅助类
+│   │   └── TestFilterHelper.php # 筛选辅助类
+│   ├── Actions/               # 控制器动作类
+│   │   └── TestExportAction.php # 导出动作
+│   └── TestController.php     # 主控制器
+├── Commands/                   # 命令行工具
+│   └── TestCommand.php        # 示例命令
+├── Config/                     # 配置文件
+│   └── test.php               # 模块配置
+├── Databases/                  # 数据库相关
+│   ├── GenerateSql/           # SQL文件
+│   │   ├── test_items.sql     # 创建数据表的SQL
+│   │   └── test_logs.sql      # 日志表SQL
+│   └── Repositories/          # 数据仓库(后台专用)
+│       └── TestRepository.php # 测试仓库
+├── Docs/                       # 文档目录
+│   ├── README.md              # 模块文档索引
+│   ├── 设计文档.md             # 设计文档
+│   └── 开发指南.md             # 开发指南
+├── Dtos/                       # 数据传输对象
+│   └── TestDto.php            # 测试DTO
+├── Enums/                      # 枚举类型定义
+│   ├── TEST_STATUS.php        # 状态枚举
+│   └── TEST_TYPE.php          # 类型枚举
+├── Events/                     # 事件类
+│   └── TestCreatedEvent.php   # 测试创建事件
+├── Exceptions/                 # 自定义异常
+│   └── TestException.php      # 测试异常
+├── Listeners/                  # 事件监听器
+│   └── TestCreatedListener.php # 测试创建监听器
+├── Logics/                     # 业务逻辑类(内部使用)
+│   └── Test.php               # 测试逻辑
+├── Models/                     # 数据模型
+│   ├── TestItem.php           # 测试项目模型
+│   └── TestLog.php            # 测试日志模型
+├── Providers/                  # 服务提供者
+│   └── TestServiceProvider.php # 测试服务提供者
+├── Services/                   # 服务类(对外接口)
+│   └── TestService.php        # 测试服务
+├── Validations/                # 验证类(业务验证)
+│   └── TestCreateValidation.php # 创建验证
+├── Validators/                 # 验证器(单一验证逻辑)
+│   └── TestStatusValidator.php # 状态验证器
+└── Tests/                      # 测试目录
+    ├── TestServiceTest.php     # 服务测试
+    └── test_manual.php         # 手动测试脚本
+```
+
+### 2.2 目录说明
+
+| 目录 | 用途 | 说明 |
+|------|------|------|
+| **AdminControllers/** | 后台管理界面 | 继承自UCore\DcatAdmin\AdminController |
+| **Commands/** | 命令行工具 | 定时任务、数据处理等命令 |
+| **Config/** | 配置文件 | 模块相关配置参数 |
+| **Databases/** | 数据库相关 | SQL文件和Repository类 |
+| **Docs/** | 文档目录 | 模块设计和开发文档 |
+| **Dtos/** | 数据传输对象 | 继承自UCore\Dto\BaseDto |
+| **Enums/** | 枚举定义 | 使用PHP enum语法,避免魔法数字 |
+| **Events/** | 事件类 | 模块间通信事件 |
+| **Exceptions/** | 自定义异常 | 业务异常处理 |
+| **Listeners/** | 事件监听器 | 处理事件响应 |
+| **Logics/** | 业务逻辑 | 内部业务处理,不对外暴露 |
+| **Models/** | 数据模型 | 继承自UCore\ModelCore,无业务逻辑 |
+| **Providers/** | 服务提供者 | 注册服务和事件 |
+| **Services/** | 服务接口 | 对外提供功能,调用Logics层 |
+| **Validations/** | 验证类 | 复合验证逻辑 |
+| **Validators/** | 验证器 | 单一验证逻辑 |
+| **Tests/** | 测试文件 | 单元测试和手动测试 |
+
+## 3. 架构设计
+
+### 3.1 分层架构
+
+Test模块采用标准的分层架构设计:
+
+```
+┌─────────────────┐
+│   Controllers   │ ← HTTP请求处理
+├─────────────────┤
+│    Services     │ ← 对外服务接口
+├─────────────────┤
+│     Logics      │ ← 内部业务逻辑
+├─────────────────┤
+│     Models      │ ← 数据模型层
+└─────────────────┘
+```
+
+### 3.2 设计原则
+
+1. **单一职责原则**:每个类只负责一个功能领域
+2. **关注点分离**:模型只负责数据结构,业务逻辑由Logic类处理
+3. **依赖注入**:通过构造函数注入依赖,提高可测试性
+4. **事务完整性**:涉及多个操作的功能使用数据库事务
+5. **日志记录**:关键操作记录详细日志
+
+### 3.3 模块交互
+
+- **服务层对外**:其他模块只能通过Services层访问功能
+- **逻辑层内部**:Logic类处理具体业务规则
+- **事件通信**:模块间通过事件进行松耦合通信
+- **数据访问**:Repository层仅供后台管理使用
+
+## 4. 开发规范
+
+### 4.1 命名规范
+
+#### 4.1.1 类命名
+- **模型类**:继承自`\UCore\ModelCore`,如`TestItem`
+- **服务类**:以`Service`结尾,如`TestService`
+- **逻辑类**:简单类名,如`Test`
+- **验证类**:以`Validation`结尾,如`TestCreateValidation`
+- **验证器**:以`Validator`结尾,如`TestStatusValidator`
+- **枚举类**:全大写,如`TEST_STATUS`
+- **DTO类**:以`Dto`结尾,如`TestDto`
+
+#### 4.1.2 数据库命名
+- **表名前缀**:使用模块前缀,如`test_`
+- **全局前缀**:所有表都有`kku_`前缀
+- **完整表名**:`kku_test_items`、`kku_test_logs`
+
+#### 4.1.3 命名空间
+- **基础命名空间**:`App\Module\Test`
+- **Handler命名空间**:`App\Module\AppGame\Handler`(接口层)
+
+### 4.2 代码规范
+
+#### 4.2.1 模型设计
+```php
+<?php
+
+namespace App\Module\Test\Models;
+
+use UCore\ModelCore;
+
+/**
+ * 测试项目模型
+ *
+ * field start
+ * @property int $id 主键ID
+ * @property string $name 项目名称
+ * @property int $status 状态
+ * @property \Carbon\Carbon $created_at 创建时间
+ * @property \Carbon\Carbon $updated_at 更新时间
+ * field end
+ */
+class TestItem extends ModelCore
+{
+    // attrlist start
+    protected $fillable = [
+        'name',
+        'status',
+    ];
+    // attrlist end
+
+    /**
+     * 状态访问器
+     */
+    public function getStatusNameAttribute(): string
+    {
+        return TEST_STATUS::getName($this->status);
+    }
+}
+```
+
+#### 4.2.2 服务层设计
+```php
+<?php
+
+namespace App\Module\Test\Services;
+
+use App\Module\Test\Dtos\TestDto;
+use App\Module\Test\Logics\Test as TestLogic;
+
+/**
+ * 测试服务类
+ *
+ * 对外提供测试相关功能接口
+ */
+class TestService
+{
+    /**
+     * 创建测试项目
+     *
+     * @param array $data 项目数据
+     * @return TestDto
+     */
+    public static function createTest(array $data): TestDto
+    {
+        $result = TestLogic::createTest($data);
+        return TestDto::fromModel($result);
+    }
+
+    /**
+     * 获取测试项目列表
+     *
+     * @param array $filters 筛选条件
+     * @return array
+     */
+    public static function getTestList(array $filters = []): array
+    {
+        return TestLogic::getTestList($filters);
+    }
+}
+```
+
+#### 4.2.3 枚举设计
+```php
+<?php
+
+namespace App\Module\Test\Enums;
+
+/**
+ * 测试状态枚举
+ */
+enum TEST_STATUS: int
+{
+    case PENDING = 1;    // 待处理
+    case PROCESSING = 2; // 处理中
+    case COMPLETED = 3;  // 已完成
+    case FAILED = 4;     // 失败
+
+    /**
+     * 获取状态名称
+     */
+    public function getName(): string
+    {
+        return match ($this) {
+            self::PENDING => '待处理',
+            self::PROCESSING => '处理中',
+            self::COMPLETED => '已完成',
+            self::FAILED => '失败',
+        };
+    }
+
+    /**
+     * 获取所有状态
+     */
+    public static function getAll(): array
+    {
+        return [
+            self::PENDING->value => self::PENDING->getName(),
+            self::PROCESSING->value => self::PROCESSING->getName(),
+            self::COMPLETED->value => self::COMPLETED->getName(),
+            self::FAILED->value => self::FAILED->getName(),
+        ];
+    }
+}
+```
+
+### 4.3 验证机制
+
+#### 4.3.1 Validation类
+```php
+<?php
+
+namespace App\Module\Test\Validations;
+
+use UCore\Validation\ValidationCore;
+
+/**
+ * 测试创建验证类
+ */
+class TestCreateValidation extends ValidationCore
+{
+    public function rules($rules = []): array
+    {
+        return [
+            ['name', 'required'],
+            ['name', 'string', 'max' => 255],
+            ['status', 'integer', 'min' => 1],
+        ];
+    }
+
+    public function default(): array
+    {
+        return [
+            'status' => TEST_STATUS::PENDING->value,
+        ];
+    }
+}
+```
+
+#### 4.3.2 Validator类
+```php
+<?php
+
+namespace App\Module\Test\Validators;
+
+use UCore\Validation\ValidatorCore;
+
+/**
+ * 测试状态验证器
+ */
+class TestStatusValidator extends ValidatorCore
+{
+    public function validate($value, $arg = null): bool
+    {
+        if (!in_array($value, array_keys(TEST_STATUS::getAll()))) {
+            $this->addError($arg, '状态值无效');
+            return false;
+        }
+        return true;
+    }
+}
+```
+
+## 5. 最佳实践
+
+### 5.1 数据库设计
+
+#### 5.1.1 表结构设计
+```sql
+-- 测试项目表
+CREATE TABLE `kku_test_items` (
+  `id` int NOT NULL AUTO_INCREMENT COMMENT '主键ID',
+  `name` varchar(255) NOT NULL COMMENT '项目名称',
+  `description` text COMMENT '项目描述',
+  `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态:1待处理,2处理中,3已完成,4失败',
+  `config` json DEFAULT NULL COMMENT '配置信息',
+  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
+  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
+  PRIMARY KEY (`id`),
+  KEY `idx_status` (`status`),
+  KEY `idx_created_at` (`created_at`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试项目表';
+
+-- 测试日志表
+CREATE TABLE `kku_test_logs` (
+  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '日志ID',
+  `test_id` int NOT NULL COMMENT '测试项目ID',
+  `action` varchar(100) NOT NULL COMMENT '操作类型',
+  `message` text COMMENT '日志消息',
+  `data` json DEFAULT NULL COMMENT '相关数据',
+  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
+  PRIMARY KEY (`id`),
+  KEY `idx_test_id` (`test_id`),
+  KEY `idx_action` (`action`),
+  KEY `idx_created_at` (`created_at`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试日志表';
+```
+
+#### 5.1.2 索引设计原则
+- **主键索引**:每个表必须有主键
+- **外键索引**:关联字段建立索引
+- **查询索引**:常用查询条件建立索引
+- **复合索引**:多字段查询建立复合索引
+
+### 5.2 事件系统
+
+#### 5.2.1 事件定义
+```php
+<?php
+
+namespace App\Module\Test\Events;
+
+use App\Module\Test\Models\TestItem;
+use Illuminate\Foundation\Events\Dispatchable;
+
+/**
+ * 测试创建事件
+ */
+class TestCreatedEvent
+{
+    use Dispatchable;
+
+    public TestItem $testItem;
+
+    public function __construct(TestItem $testItem)
+    {
+        $this->testItem = $testItem;
+    }
+}
+```
+
+#### 5.2.2 事件监听器
+```php
+<?php
+
+namespace App\Module\Test\Listeners;
+
+use App\Module\Test\Events\TestCreatedEvent;
+
+/**
+ * 测试创建监听器
+ */
+class TestCreatedListener
+{
+    public function handle(TestCreatedEvent $event): void
+    {
+        // 处理测试创建后的逻辑
+        // 如:发送通知、更新统计等
+    }
+}
+```
+
+### 5.3 后台管理
+
+#### 5.3.1 控制器设计
+```php
+<?php
+
+namespace App\Module\Test\AdminControllers;
+
+use App\Module\Test\AdminControllers\Helper\TestGridHelper;
+use App\Module\Test\AdminControllers\Helper\TestFormHelper;
+use App\Module\Test\Repositories\TestRepository;
+use UCore\DcatAdmin\AdminController;
+
+/**
+ * 测试后台控制器
+ *
+ * @route /admin/test-items
+ */
+class TestController extends AdminController
+{
+    protected string $title = '测试管理';
+    protected string $repository = TestRepository::class;
+
+    protected function grid()
+    {
+        return TestGridHelper::make($this->repository());
+    }
+
+    protected function form()
+    {
+        return TestFormHelper::make();
+    }
+}
+```
+
+### 5.4 测试规范
+
+#### 5.4.1 单元测试
+```php
+<?php
+
+namespace App\Module\Test\Tests;
+
+use App\Module\Test\Services\TestService;
+use PHPUnit\Framework\TestCase;
+
+/**
+ * 测试服务单元测试
+ */
+class TestServiceTest extends TestCase
+{
+    public function testCreateTest()
+    {
+        $data = [
+            'name' => '测试项目',
+            'description' => '这是一个测试项目',
+        ];
+
+        $result = TestService::createTest($data);
+
+        $this->assertNotNull($result);
+        $this->assertEquals($data['name'], $result->name);
+    }
+}
+```
+
+#### 5.4.2 手动测试
+```php
+<?php
+// app/Module/Test/Tests/test_manual.php
+
+require_once __DIR__ . '/../../../../bootstrap/app.php';
+
+use App\Module\Test\Services\TestService;
+
+// 测试创建功能
+$data = [
+    'name' => '手动测试项目',
+    'description' => '手动测试描述',
+];
+
+try {
+    $result = TestService::createTest($data);
+    echo "创建成功:" . json_encode($result, JSON_UNESCAPED_UNICODE) . "\n";
+} catch (Exception $e) {
+    echo "创建失败:" . $e->getMessage() . "\n";
+}
+```
+
+## 6. 参考示例
+
+### 6.1 物品模块参考
+
+Test模块可以参考GameItems模块的以下设计:
+
+- **冻结功能**:物品冻结机制的实现方式
+- **拆堆模式**:统一属性物品的数量管理
+- **事务处理**:多步骤操作的事务保护
+- **日志记录**:完整的操作审计机制
+
+### 6.2 Mex模块参考
+
+Test模块可以参考Mex模块的以下设计:
+
+- **撮合算法**:复杂业务逻辑的处理方式
+- **状态机**:订单状态的流转管理
+- **定时任务**:后台任务的设计模式
+- **多币种适配**:灵活的配置管理
+
+### 6.3 农场模块参考
+
+Test模块可以参考Farm模块的以下设计:
+
+- **生长周期**:时间相关业务的处理
+- **灾害系统**:随机事件的实现机制
+- **升级系统**:进度管理的设计模式
+- **神灵加持**:临时效果的管理方式
+
+## 7. 开发指南
+
+### 7.1 新建模块步骤
+
+1. **创建目录结构**:按照标准目录结构创建文件夹
+2. **定义枚举类型**:先定义业务相关的枚举
+3. **设计数据模型**:创建数据库表和模型类
+4. **实现业务逻辑**:编写Logic类处理业务规则
+5. **提供服务接口**:创建Service类对外提供功能
+6. **添加验证机制**:实现Validation和Validator类
+7. **创建后台管理**:实现AdminController和Helper类
+8. **编写测试用例**:添加单元测试和手动测试
+9. **完善文档**:编写详细的模块文档
+
+### 7.2 注意事项
+
+1. **模型无业务逻辑**:模型只负责数据结构定义
+2. **服务层对外**:其他模块只能通过Service层访问
+3. **事务保护**:多步骤操作必须使用数据库事务
+4. **异常处理**:Handler中不设置异常处理,继续抛出
+5. **日志记录**:关键操作记录详细日志
+6. **中文注释**:代码中添加中文注释说明
+7. **文档维护**:及时更新模块文档
+
+### 7.3 扩展建议
+
+1. **功能扩展**:基于现有架构添加新功能
+2. **性能优化**:添加缓存机制和索引优化
+3. **监控告警**:实现业务监控和异常告警
+4. **国际化**:支持多语言和多地区
+5. **API接口**:提供RESTful API接口
+6. **移动端适配**:支持移动端应用接入
+
+---
+
+**最后更新时间**:2025年06月16日
+**文档版本**:v1.0
+**维护人员**:开发团队
+```