231 lines
12 KiB
Plaintext
231 lines
12 KiB
Plaintext
---
|
||
alwaysApply: 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<T> 与 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 静态扫描无阻断级问题。
|
||
|
||
- 回滚准备
|
||
- 是否具备配置开关/灰度发布策略；是否提供回滚脚本；数据库迁移是否可逆（或给出补偿方案）。
|