life-script启动后地址栏无限重复切换bug修复
This commit is contained in:
@@ -0,0 +1,85 @@
|
||||
---
|
||||
description:
|
||||
alwaysApply: true
|
||||
enabled: true
|
||||
updatedAt: 2025-12-24T03:15:40.776Z
|
||||
provider:
|
||||
---
|
||||
|
||||
# 项目开发规则
|
||||
|
||||
## 基础设置
|
||||
|
||||
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级别日志
|
||||
Reference in New Issue
Block a user