life-script启动后地址栏无限重复切换bug修复
This commit is contained in:
@@ -79,143 +79,3 @@ type: "always_apply"
|
||||
42. 关键业务操作必须记录操作日志
|
||||
43. 异常信息要包含足够的上下文信息
|
||||
44. 生产环境禁止输出debug级别日志
|
||||
|
||||
## Java Spring Boot 项目开发与代码质量保障规范（扩展）
|
||||
|
||||
适用范围：本规范适用于 EmotionMuseum 项目所有后端模块。若与本文件前文条款或现有项目规范冲突，以更严格者为准。
|
||||
|
||||
### 一、代码规范完善
|
||||
|
||||
- 编码标准
|
||||
- 严格开启编译参数校验与空指针警告，禁止忽略 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 静态扫描无阻断级问题。
|
||||
|
||||
- 回滚准备
|
||||
- 是否具备配置开关/灰度发布策略；是否提供回滚脚本；数据库迁移是否可逆（或给出补偿方案）。
|
||||
|
||||
@@ -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级别日志
|
||||
@@ -17,6 +17,7 @@ import lombok.extern.slf4j.Slf4j;
|
||||
import org.springframework.beans.factory.annotation.Autowired;
|
||||
import org.springframework.beans.BeanUtils;
|
||||
import org.springframework.stereotype.Service;
|
||||
import org.springframework.util.ObjectUtils;
|
||||
import org.springframework.util.StringUtils;
|
||||
|
||||
import java.math.BigDecimal;
|
||||
@@ -152,7 +153,7 @@ public class LifeEventServiceImpl extends ServiceImpl<LifeEventMapper, LifeEvent
|
||||
}
|
||||
|
||||
// 调用Coze AI进行疗愈回复
|
||||
String aiGeneratedContent = generateHealingByAi(request, currentUserId);
|
||||
String aiGeneratedContent = generateHealingByAi(event);
|
||||
if (StringUtils.hasText(aiGeneratedContent)) {
|
||||
event.setAiReply(aiGeneratedContent);
|
||||
}
|
||||
@@ -164,24 +165,23 @@ public class LifeEventServiceImpl extends ServiceImpl<LifeEventMapper, LifeEvent
|
||||
/**
|
||||
* 调用Coze AI生成疗愈内容
|
||||
*
|
||||
* @param request 创建请求
|
||||
* @param userId 用户ID
|
||||
* @param event 人生事件
|
||||
* @return AI生成的疗愈内容，失败时返回null
|
||||
*/
|
||||
private String generateHealingByAi(LifeEventCreateRequest request, String userId) {
|
||||
private String generateHealingByAi(LifeEvent event) {
|
||||
try {
|
||||
// 组装AI输入
|
||||
String input = assembleHealingInput(request);
|
||||
log.info("开始调用AI生成疗愈回复，用户ID: {}, 输入长度: {}", userId, input.length());
|
||||
String input = assembleHealingInput(event);
|
||||
log.info("开始调用AI生成疗愈回复，用户ID: {}, 输入长度: {}", event.getUserId(), input.length());
|
||||
|
||||
// 调用Coze工作流
|
||||
String result = aiChatService.callWorkflowByConfigKey(COZE_HEALING_CONFIG_KEY, input, userId);
|
||||
String result = aiChatService.callWorkflowByConfigKey(COZE_HEALING_CONFIG_KEY, input, event.getUserId());
|
||||
|
||||
log.info("AI生成疗愈回复完成，用户ID: {}, 结果长度: {}", userId, result != null ? result.length() : 0);
|
||||
log.info("AI生成疗愈回复完成，用户ID: {}, 结果长度: {}", event.getUserId(), result != null ? result.length() : 0);
|
||||
return result;
|
||||
|
||||
} catch (Exception e) {
|
||||
log.error("AI生成疗愈回复失败，用户ID: {}, 错误: {}", userId, e.getMessage(), e);
|
||||
log.error("AI生成疗愈回复失败，用户ID: {}, 错误: {}", event.getUserId(), e.getMessage(), e);
|
||||
// AI调用失败不影响事件创建，返回null
|
||||
return null;
|
||||
}
|
||||
@@ -190,30 +190,30 @@ public class LifeEventServiceImpl extends ServiceImpl<LifeEventMapper, LifeEvent
|
||||
/**
|
||||
* 组装AI疗愈输入内容
|
||||
*
|
||||
* @param request 创建请求
|
||||
* @param event 人生事件
|
||||
* @return 格式化的输入字符串
|
||||
*/
|
||||
private String assembleHealingInput(LifeEventCreateRequest request) {
|
||||
private String assembleHealingInput(LifeEvent event) {
|
||||
StringBuilder sb = new StringBuilder();
|
||||
|
||||
// 标题
|
||||
if (StringUtils.hasText(request.getTitle())) {
|
||||
sb.append("【事件标题】").append(request.getTitle()).append("\n");
|
||||
if (StringUtils.hasText(event.getTitle())) {
|
||||
sb.append("【事件标题】").append(event.getTitle()).append("\n");
|
||||
}
|
||||
|
||||
// 发生时间
|
||||
if (StringUtils.hasText(request.getEventDate())) {
|
||||
sb.append("【发生时间】").append(request.getEventDate()).append("\n");
|
||||
if (!ObjectUtils.isEmpty(event.getEventDate())) {
|
||||
sb.append("【发生时间】").append(event.getEventDate()).append("\n");
|
||||
}
|
||||
|
||||
// 经历详解
|
||||
if (StringUtils.hasText(request.getContent())) {
|
||||
sb.append("【经历详解】").append(request.getContent()).append("\n");
|
||||
if (StringUtils.hasText(event.getContent())) {
|
||||
sb.append("【经历详解】").append(event.getContent()).append("\n");
|
||||
}
|
||||
|
||||
// 情绪类型
|
||||
if (StringUtils.hasText(request.getEmotionType())) {
|
||||
sb.append("【情绪类型】").append(request.getEmotionType()).append("\n");
|
||||
if (StringUtils.hasText(event.getEmotionType())) {
|
||||
sb.append("【情绪类型】").append(event.getEmotionType()).append("\n");
|
||||
}
|
||||
|
||||
return sb.toString().trim();
|
||||
@@ -258,6 +258,12 @@ public class LifeEventServiceImpl extends ServiceImpl<LifeEventMapper, LifeEvent
|
||||
event.setEmotionScore(BigDecimal.valueOf(request.getEmotionScore()));
|
||||
}
|
||||
|
||||
// 调用Coze AI进行疗愈回复
|
||||
String aiGeneratedContent = generateHealingByAi(event);
|
||||
if (StringUtils.hasText(aiGeneratedContent)) {
|
||||
event.setAiReply(aiGeneratedContent);
|
||||
}
|
||||
|
||||
this.updateById(event);
|
||||
return convertToResponse(event);
|
||||
}
|
||||
|
||||
@@ -55,10 +55,16 @@ api.interceptors.response.use(
|
||||
if (error.response) {
|
||||
const { status, data } = error.response;
|
||||
if (status === 401) {
|
||||
// token 过期，清除登录状态
|
||||
// token 过期或无效，清除所有登录相关状态
|
||||
localStorage.removeItem('access_token');
|
||||
localStorage.removeItem('refresh_token');
|
||||
window.location.href = '/';
|
||||
localStorage.removeItem('life_trajectory_v3'); // 清除 Zustand 持久化状态
|
||||
|
||||
// 避免重复跳转导致的无限循环
|
||||
if (window.location.pathname !== '/') {
|
||||
window.location.href = '/';
|
||||
}
|
||||
return Promise.reject(new Error('未授权访问，请重新登录'));
|
||||
}
|
||||
return Promise.reject(new Error(data?.message || `请求失败: ${status}`));
|
||||
}
|
||||
|
||||
@@ -8,9 +8,9 @@ alter table emotion_museum.t_user_profile
|
||||
|
||||
-- 消息
|
||||
alter table emotion_museum.t_message
|
||||
add message_order varchar(100) null comment '职业';
|
||||
add message_order varchar(100) null comment '消息顺序';
|
||||
|
||||
-- AI
|
||||
-- AI 配置
|
||||
alter table emotion_museum.t_ai_config
|
||||
add client_id VARCHAR(200) COMMENT '客户端ID (OAuth认证)',
|
||||
add client_secret VARCHAR(500) COMMENT '客户端密钥 (OAuth认证，加密存储)',
|
||||
|
||||
Reference in New Issue
Block a user