60f4752124
refactor(ArticleRepository): 修正@Param注解导入错误并优化查询方法 fix(ArticleService): 解决事务回滚问题并优化日志配置 feat(SecurityConfig): 添加Spring Security配置禁用默认认证 docs: 添加详细API文档README_API.md feat(HelpController): 实现Markdown文档渲染API style: 清理无用注释和导入 build: 更新pom.xml依赖和插件配置 chore: 优化application.properties配置
110 lines
4.6 KiB
Markdown
110 lines
4.6 KiB
Markdown
# 技术问题总结文档
|
||
|
||
本文档总结了在项目开发和调试过程中遇到的主要技术问题、原因分析及解决方案。
|
||
|
||
## 一、事务回滚问题（核心问题）
|
||
|
||
### 问题描述
|
||
API接口调用时出现500错误，响应信息为："Transaction silently rolled back because it has been marked as rollback-only"（事务被静默回滚，因为它已被标记为只能回滚）。
|
||
|
||
### 根本原因
|
||
通过详细分析，发现问题的根本原因是**@Param注解导入错误**：
|
||
|
||
在`ArticleRepository`接口中，项目使用的是Spring Data JPA框架，但错误地导入了MyBatis的`@Param`注解：
|
||
```java
|
||
import org.apache.ibatis.annotations.Param; // 错误的导入
|
||
```
|
||
|
||
这导致Spring Data JPA无法正确识别和绑定查询参数，从而在执行数据库操作时抛出异常，最终导致事务被标记为只能回滚。
|
||
|
||
### 解决方案
|
||
将MyBatis的`@Param`注解替换为Spring Data JPA正确的`@Param`注解：
|
||
```java
|
||
import org.springframework.data.repository.query.Param; // 正确的导入
|
||
```
|
||
|
||
## 二、方法参数与@Param注解不匹配问题
|
||
|
||
### 问题描述
|
||
在`ArticleRepository`中存在多个查询方法的参数名称与`@Param`注解值不匹配的情况：
|
||
|
||
1. `findPublishedByAuthor`方法：
|
||
- 方法参数为`id`
|
||
- `@Param`注解值为`"authorId"`
|
||
- 但`Article`实体中不存在`authorId`字段
|
||
|
||
2. `findPublishedByCategory`方法：
|
||
- 方法参数为`typeid`
|
||
- `@Param`注解值为`"categoryId"`
|
||
- JPQL查询中使用`:categoryId`参数
|
||
|
||
### 解决方案
|
||
1. 对于`findPublishedByAuthor`方法：
|
||
- 由于`Article`实体中不存在`authorId`字段，移除了相关的查询条件和参数
|
||
- 仅保留状态筛选条件：`SELECT a FROM Article a WHERE a.status = 1`
|
||
- 修改方法签名为无参方法：`List<Article> findPublishedByAuthor()`
|
||
|
||
2. 对于`findPublishedByCategory`方法：
|
||
- 统一参数名称，修改方法参数名为`categoryId`
|
||
- 确保`@Param`注解值和JPQL查询参数名保持一致
|
||
|
||
## 三、事务配置问题
|
||
|
||
### 问题描述
|
||
在`ArticleService`的`getArticleById`方法中，最初使用了`@Transactional(readOnly = true)`注解，但方法内部却调用了`incrementViewCount`写操作方法，导致事务冲突。
|
||
|
||
### 解决方案
|
||
尝试了两种方案：
|
||
1. 第一种方案：将`@Transactional(readOnly = true)`修改为普通的`@Transactional`注解，允许在事务内执行写操作
|
||
2. 第二种方案（最终采用）：为了排查问题，暂时注释掉了`incrementViewCount`方法调用，将事务配置改回`@Transactional(readOnly = true)`
|
||
|
||
但根本问题解决后（修复了@Param注解导入错误），两种配置都可以正常工作。
|
||
|
||
## 四、配置文件优化问题
|
||
|
||
### 问题描述
|
||
项目的`application.properties`配置文件存在一些可以优化的地方，包括：
|
||
1. 数据库URL中的拼写错误
|
||
2. 未使用的MyBatis配置残留
|
||
3. 数据库连接池配置不完整
|
||
4. JPA性能配置缺失
|
||
5. Redis连接池配置不合理
|
||
6. 安全性配置不完善
|
||
|
||
### 解决方案
|
||
对配置文件进行了全面优化，主要包括：
|
||
|
||
1. **数据库配置优化**：
|
||
- 修复了数据库URL拼写错误
|
||
- 添加了字符集、SSL、时区等连接参数
|
||
|
||
2. **移除不必要的配置**：
|
||
- 删除了未使用的MyBatis配置
|
||
|
||
3. **性能优化配置**：
|
||
- 完善了Hikari连接池配置
|
||
- 添加了JPA批量操作和缓存配置
|
||
- 优化了Redis连接池参数
|
||
|
||
4. **安全性增强**：
|
||
- 限制了Actuator暴露的端点
|
||
- 完善了JWT和CORS配置
|
||
|
||
5. **添加必要的配置**：
|
||
- 会话管理配置
|
||
- 国际化配置
|
||
- 响应编码配置
|
||
|
||
## 五、其他相关问题
|
||
|
||
### Article实体与查询方法不匹配
|
||
在排查过程中发现，`ArticleRepository`中的某些查询方法引用了`Article`实体中不存在的字段（如`authorId`），这表明在开发过程中可能存在实体设计与数据访问层不一致的情况。
|
||
|
||
### 日志级别配置
|
||
为了更好地排查问题，调整了日志配置，将核心包的日志级别设置为DEBUG，同时限制了其他框架的日志输出，避免日志信息过于冗长。
|
||
|
||
## 六、总结
|
||
|
||
本次问题排查和修复过程中，我们发现了多个相互关联的技术问题，其中最核心的问题是**@Param注解导入错误**。这一问题导致了一系列连锁反应，最终表现为事务回滚错误。
|
||
|
||
通过系统性地分析和解决这些问题，我们不仅修复了API功能，还优化了项目的整体配置和性能。这个过程也提醒我们在开发过程中要特别注意框架注解的正确使用，以及保持代码各部分之间的一致性。 |