4.4 KiB
4.4 KiB
trigger, alwaysApply
| trigger | alwaysApply |
|---|---|
| always_on | true |
项目开发规则
基础设置
- 保持对话语言为中文
- 不允许在未经允许的情况下删除代码和文件,不允许破坏已经正常的业务代码
- 执行终端命令时要关注执行情况，避免无效等待
代码规范
- 生成代码时必须添加类级和函数级注释
- 使用import导包，禁止使用全限定名称引用类
- 禁止使用枚举类型作为entity、request、response、dto对象的字段类型，禁止以枚举类作为方法的入参，确保接口的通用性和可扩展性
- 新增数据的id使用已存在的雪花算法生成器生成
架构规范
- 所有开发必须遵循当前项目规范
- Controller层禁止添加业务逻辑
- 使用全局异常处理，禁止使用try-catch
- 前端接口访问尽可能走网关调用
接口设计规范
- Controller层接口定义要完整：
- 入参使用request封装传递到service层
- service层的方法命名与controller层定义的接口的方法名称保持一致
- 出参使用response封装由service层传递到controller层
- 禁止在controller层做entity/domain对象与request/response的转换
- 使用项目已有的Result做接口返回
- 接口和方法参数不允许超过两个，超过时使用request或DTO对象封装
- Controller层路由禁止添加/api前缀
- Controller层接口的Mapping注解value属性值不允许重复且不允许为空，必须明确指定value属性值且使用驼峰结构命名，避免使用下划线分隔符。所有接口注解必须显式指定value属性，如@GetMapping(value = "/page")、@PostMapping(value = "/create")等，禁止使用@GetMapping()或@PostMapping等空注解形式
- 用户相关接口禁止直接传递用户id，需要后端根据token获取当前登录用户信息
- 禁止使用/{param}格式的路径参数，避免网关路由冲突和分发错误
- 路径参数统一使用@RequestParam而非@PathVariable，确保网关分发准确性
- 接口路径命名应具有明确的语义，避免使用通用词汇如/get、/list等
- 批量操作接口应使用专门的Request对象封装参数，而非直接传递List
- 接口路径应避免层级过深，建议不超过3级路径结构
- 更新操作应直接使用封装了ID和其他数据的Request对象，而不是单独传递ID参数。Service层方法应保持参数简洁，业务逻辑所需数据应全部包含在Request对象中
- Controller层接口应保持简洁，避免为特定字段创建独立的更新方法（如updateStatus等），应只保留一个通用的update方法，具体的业务逻辑在Service层实现
- Service层在执行更新操作时，应对每个字段进行空值检查，只更新非空字段，避免空字段覆盖原有值，确保数据完整性
- Controller层应避免创建多个特定条件的查询接口，只保留一个分页查询方法，通过在请求对象中包含所有可查询字段来支持不同的查询需求
- 分页查询接口应支持模糊查询和精确查询，通过在Service层根据字段类型和业务需求判断查询方式
环境配置
- 为不同环境(local、dev、prod)创建单独配置文件，部署时通过参数选择
- 启动服务时禁止擅自修改端口号，使用配置文件中的端口设置
数据库规范
- 所有数据表必须包含创建时间(create_time)和更新时间(update_time)字段
- 删除操作优先使用逻辑删除，添加deleted字段标识
- 数据库字段命名使用下划线分隔，Java实体类使用驼峰命名
- 优先使用LambdaQueryWrapper构造条件查询，避免硬编码字段名
- 使用Lambda表达式引用实体类属性，提高代码可维护性和类型安全
- 复杂查询条件应使用LambdaQueryWrapper的链式调用，保持代码清晰
- 避免在查询条件中使用字符串字段名，防止字段名变更导致的运行时错误
安全规范
- 所有外部输入必须进行参数校验
- 敏感信息不得在日志中输出
- 数据库操作必须使用参数化查询，防止SQL注入
性能规范
- 避免N+1查询问题，合理使用批量查询
- 大数据量查询必须分页处理
- 缓存策略要考虑数据一致性问题
日志规范
- 关键业务操作必须记录操作日志
- 异常信息要包含足够的上下文信息
- 生产环境禁止输出debug级别日志