happy-life-star/.qoder/rules/rules.md

trigger, alwaysApply

trigger	alwaysApply
always_on	true

项目开发规则

基础设置

1. 保持对话语言为中文
2. 不允许在未经允许的情况下删除代码和文件,不允许破坏已经正常的业务代码
3. 执行终端命令时要关注执行情况，避免无效等待

代码规范

4. 生成代码时必须添加类级和函数级注释
5. 使用import导包，禁止使用全限定名称引用类
6. 禁止使用枚举类型作为entity、request、response、dto对象的字段类型，禁止以枚举类作为方法的入参，确保接口的通用性和可扩展性
7. 新增数据的id使用已存在的雪花算法生成器生成

架构规范

8. 所有开发必须遵循当前项目规范
9. Controller层禁止添加业务逻辑
10. 使用全局异常处理，禁止使用try-catch
11. 前端接口访问尽可能走网关调用

接口设计规范

12. Controller层接口定义要完整：
    • 入参使用request封装传递到service层
    • service层的方法命名与controller层定义的接口的方法名称保持一致
    • 出参使用response封装由service层传递到controller层
    • 禁止在controller层做entity/domain对象与request/response的转换
    • 使用项目已有的Result做接口返回
13. 接口和方法参数不允许超过两个，超过时使用request或DTO对象封装
14. Controller层路由禁止添加/api前缀
15. Controller层接口的Mapping注解value属性值不允许重复且不允许为空，必须明确指定value属性值且使用驼峰结构命名，避免使用下划线分隔符。所有接口注解必须显式指定value属性，如@GetMapping(value = "/page")、@PostMapping(value = "/create")等，禁止使用@GetMapping()或@PostMapping等空注解形式
16. 用户相关接口禁止直接传递用户id，需要后端根据token获取当前登录用户信息
17. 禁止使用/{param}格式的路径参数，避免网关路由冲突和分发错误
18. 路径参数统一使用@RequestParam而非@PathVariable，确保网关分发准确性
19. 接口路径命名应具有明确的语义，避免使用通用词汇如/get、/list等
20. 批量操作接口应使用专门的Request对象封装参数，而非直接传递List
21. 接口路径应避免层级过深，建议不超过3级路径结构
22. 更新操作应直接使用封装了ID和其他数据的Request对象，而不是单独传递ID参数。Service层方法应保持参数简洁，业务逻辑所需数据应全部包含在Request对象中
23. Controller层接口应保持简洁，避免为特定字段创建独立的更新方法（如updateStatus等），应只保留一个通用的update方法，具体的业务逻辑在Service层实现
24. Service层在执行更新操作时，应对每个字段进行空值检查，只更新非空字段，避免空字段覆盖原有值，确保数据完整性
25. Controller层应避免创建多个特定条件的查询接口，只保留一个分页查询方法，通过在请求对象中包含所有可查询字段来支持不同的查询需求
26. 分页查询接口应支持模糊查询和精确查询，通过在Service层根据字段类型和业务需求判断查询方式

环境配置

27. 为不同环境(local、dev、prod)创建单独配置文件，部署时通过参数选择
28. 启动服务时禁止擅自修改端口号，使用配置文件中的端口设置

数据库规范

29. 所有数据表必须包含创建时间(create_time)和更新时间(update_time)字段
30. 删除操作优先使用逻辑删除，添加deleted字段标识
31. 数据库字段命名使用下划线分隔，Java实体类使用驼峰命名
32. 优先使用LambdaQueryWrapper构造条件查询，避免硬编码字段名
33. 使用Lambda表达式引用实体类属性，提高代码可维护性和类型安全
34. 复杂查询条件应使用LambdaQueryWrapper的链式调用，保持代码清晰
35. 避免在查询条件中使用字符串字段名，防止字段名变更导致的运行时错误

安全规范

36. 所有外部输入必须进行参数校验
37. 敏感信息不得在日志中输出
38. 数据库操作必须使用参数化查询，防止SQL注入

性能规范

39. 避免N+1查询问题，合理使用批量查询
40. 大数据量查询必须分页处理
41. 缓存策略要考虑数据一致性问题

日志规范

42. 关键业务操作必须记录操作日志
43. 异常信息要包含足够的上下文信息
44. 生产环境禁止输出debug级别日志

---

Java Spring Boot 项目开发与代码质量保障规范（扩展）

适用范围：本规范适用于 logistics-finance 项目所有后端模块（common、gateway、auth、user、order、waybill、vehicle、finance、report、ai、file）。若与本文件前文条款或现有项目规范冲突，以更严格者为准。

一、代码规范完善

• 编码标准

  • 严格开启编译参数校验与空指针警告，禁止忽略 IDE/编译器提示。
  • 代码提交前必须通过本地编译、单元测试、静态扫描（如存在）。
  • 严禁出现魔法值：使用常量或配置项；跨模块常量放在 common 模块统一管理。
  • 日志分级：业务关键信息用 info，调试用 debug（生产禁用），异常用 error，禁止打印敏感信息（密码、密钥、Token、手机号等）。

• 命名规范

  • 类：PascalCase；方法/变量：camelCase；常量：UPPER_SNAKE_CASE；包名全小写。
  • 接口路径参照现有规则（禁止 /api 前缀、禁止 PathVariable、Mapping value 必须显式且驼峰命名）。

• 注释规范

  • 类注释需包含：职责/用途、作者、创建时间、版本；方法注释需包含：用途、参数、返回、可能抛出的异常。
  • 复杂算法/易错逻辑必须添加行内注释；废弃方法使用 @Deprecated 并标注替代方案与移除计划。

• 代码结构规范（建议包结构）

  • controller、service、service.impl、repository（mapper/dao）、domain/entity、converter、config、client（feign）、event、facade、task、util、constant。
  • DTO/Request/Response 与 Entity 分离；Controller 不做对象互转，统一在 Service/Converter 层完成。

二、分层架构规范

• Controller 层职责

  • 接收请求、参数校验（Jakarta Validation）、鉴权校验（由网关/拦截器）、调用 Service，统一使用 Result<T> 返回。
  • 禁止：业务逻辑、事务控制、数据访问、实体与请求/响应的相互转换。

• Service 层职责

  • 聚合业务逻辑、领域编排、事务边界控制（@Transactional，读写分离时仅在写方法上标注），幂等与重试策略在此实现。
  • 方法命名与 Controller 对应，入参使用 Request 对象，出参使用 Response 对象。

• Repository 层职责

  • 仅做数据访问，统一使用 MyBatis-Plus（优先 LambdaQueryWrapper，避免硬编码字段）。

• Entity 规范

  • 统一继承 BaseEntity，字段包含：created_by、create_time、updated_by、update_time、logical_delete、remark（与项目约定一致）。
  • 禁止使用枚举作为实体/DTO 字段类型；以 String/Integer 存储并在注释中补充取值说明。

三、统一异常与返回结果

• 全局异常处理

  • 继续使用 common-web 的 GlobalExceptionHandler；禁止在业务代码中大面积 try-catch，异常由全局处理。
  • 业务异常一律抛出 BusinessException；校验异常统一转为 400 语义返回。

• 统一返回结构

  • 统一使用 common-core 的 Result 与 ResultCode；保证 traceId、timestamp 一致性。
  • Controller 层仅返回 Result，不直接返回实体或集合。

• 参数校验

  • 使用 jakarta.validation 注解（@NotNull、@Size 等），在 Request 对象上标注；Controller 使用 @Validated。

四、数据库操作规范

• 设计规范

  • 数据表必须包含 create_time、update_time；删除优先逻辑删除 logical_delete；字段命名下划线风格。
  • 建议仅创建必要索引；避免外键约束（由应用层保证一致性）。

• 查询构建

  • 优先使用 LambdaQueryWrapper 和链式调用；分页查询必须使用分页插件；大数据量必须分页。
  • 避免 N+1 查询；需要时使用批量查询或联表映射。

• 事务管理

  • 仅在 Service 层声明事务；方法内仅包含数据库操作或与数据库一致性相关的远程调用；跨服务一致性使用可靠消息/补偿方案。

---

二、代码质量保障机制

• 代码审查流程（Code Review）

  • 所有变更必须走 PR；至少 1 名同组开发+1 名模块 Owner 审核通过方可合并。
  • 审查清单：命名/注释/分层边界/异常处理/日志/性能/安全/接口兼容性/测试覆盖率/静态扫描告警。
  • PR 模板需包含：改动描述、影响面、回归范围、测试说明、回滚方案。

• 静态代码分析与格式

  • 集成 Checkstyle（代码风格）、SpotBugs/PMD（潜在缺陷）、SonarQube（质量门禁），EditorConfig/格式化工具保持一致风格。
  • 质量门禁建议：
    • 新增代码覆盖率 >= 80%，全局覆盖率 >= 70%；
    • Blocker/Critical 问题为 0；
    • 重复代码率 < 3%；
    • 圈复杂度阈值：方法 < 10，类 < 80。

• 测试规范

  • 单元测试：命名 {ClassName}Test，方法名 should_xxx_when_xxx；使用 Mockito/AssertJ；隔离外部依赖。
  • 集成测试：使用 @SpringBootTest，测试容器或嵌入式组件替代真实依赖；构造典型场景与边界场景。
  • 覆盖率准则：核心业务与关键分支必须覆盖（正常/异常/边界/空数据）。
  • 用例分层：Service 层单测覆盖业务规则；Controller 层使用 MockMvc；Repository 层覆盖复杂 SQL 与多条件查询。

• 重构指导原则

  • 小步快跑、单一职责、先加测试再重构；保持对外行为一致（新增特性使用特性开关/版本控制）。
  • 严禁大规模跨模块重构合并在单次 PR；拆分为多个可审查的独立提交。

---

三、变更管理流程

• 变更前影响分析

  • 维度：接口兼容性（路径/入参/语义）、数据库（表/字段/索引/数据迁移）、配置（Nacos/环境变量）、依赖版本、性能、容量与并发、安全与合规、可回滚性。
  • 产出：影响分析文档与回滚方案（包含回滚脚本/开关）。

• 回归测试策略

  • 冒烟覆盖主干流程；模块级回归覆盖变更影响域；跨服务联调验证接口契约（通过网关）。
  • 回归范围基于依赖关系与影响分析确定；优先自动化回归，必要时补充手工用例。

• 版本管理与发布

  • 分支策略建议：
    • 主分支：master；
    • 功能分支：feature/{module}-{short-desc}；
    • 预发布：release/x.y.z；
    • 紧急修复：hotfix/x.y.z；
  • 版本号：语义化版本 SemVer（MAJOR.MINOR.PATCH），发布时打 Tag；所有服务端口遵循 280xx 约定（配置文件统一）。

• 紧急修复与常规开发

  • 紧急修复：创建 hotfix → 修复 → 快速测试 → 合并 master 与 release → 立即发布 → 追补测试与文档。
  • 常规开发：feature → PR 审核 → 合并 → 集成测试 → 发布。

---

四、持续改进机制

• 规范评审与更新

  • 每月一次质量例会，评审新增问题与改进项；规范变更需在本文件留痕（版本/日期/变更点）。

• 质量指标监控（建议在 Sonar/日志/监控平台看板化）

  • 构建成功率、静态问题趋势、单元测试覆盖率、平均修复时长、缺陷密度、接口成功率、P95/P99 响应时间、数据库慢查询比例。

• 团队培训计划

  • 新人入项必读规范与代码演练；关键模块轮训；每季度至少一次专题分享（性能调优/安全加固/重构实践）。

• 反馈闭环

  • 通过代码评审、事后复盘（Postmortem）、问题工单收敛到规范条款；指定责任人与截止时间；下次评审验证落地结果。

---

附：标准检查清单（节选）

• PR 自检

  • 命名/注释达标；无魔法值；日志分级正确且无敏感信息；空指针风险已处理；删除代码/文件已获批准。
  • Controller 不含业务逻辑；路由命名与网关规范一致；统一 Result 返回；参数校验齐全；不使用 PathVariable。
  • Service 事务边界清晰；仅更新非空字段；分页/批量/幂等校验到位。
  • Repository 使用 LambdaQueryWrapper；避免硬编码字段；SQL 有必要索引；避免 N+1。
  • 测试覆盖关键路径与边界；新增功能附带测试；CI 静态扫描无阻断级问题。

• 回滚准备

  • 是否具备配置开关/灰度发布策略；是否提供回滚脚本；数据库迁移是否可逆（或给出补偿方案）。