<think>好的，我现在遇到了
MyBatis-
Plus报错“because can not find cache of TableInfo for entity”，需要仔细分析这个问题。首先，我应该回忆一下这个错误通常发生在什么情况下。根据经验，这个错误通常和实体类的配置有关，可能是
MyBatis-
Plus在启动时无法正确解析实体类的元数据信息。
接下来，我需要考虑可能的原因。首先想到的是实体类是否使用了正确的注解，比如@TableName或者默认的表名映射是否正确。如果实体类没有正确注解，或者表名和实体类名之间的映射不符合
MyBatis-
Plus的默认规则，可能导致无法找到TableInfo的缓存。
另外，可能是
MyBatis-
Plus的配置问题，比如是否启用了实体类扫描，或者扫描路径是否正确。如果配置
文件中没有正确配置
mapperScan，或者实体类所在的包没有被扫描到，也会导致这个问题。
还有可能是版本兼容性问题，比如
MyBatis-
Plus的版本和Spring Boot或其他依赖库的版本不兼容，导致某些功能无法正常工作。这时候需要检查pom.
xml或者build.gradle中的依赖版本是否正确。
另外，缓存机制可能也是一个原因。
MyBatis-
Plus在启动时会缓存实体类的信息，如果缓存没有正确生成或者被意外清除，可能导致这个问题。可以尝试清理缓存并重新构建项目，或者检查是否有代码在运行时修改了缓存。
还有一种可能性是实体类中存在复杂的继承关系或者使用了某些
MyBatis-
Plus不支持的特性，导致解析失败。需要检查实体类的结构，确保没有使用不支持的注解或配置。
接下来，我应该按照这些可能的原因逐一排查。首先检查实体类的注解是否正确，特别是@TableName是否配置正确，或者表名是否符合默认的命名策略。例如，如果数据库表名是下划线格式，而实体类名是驼峰格式，可能需要配置全局的命名策略。
然后检查
MyBatis-
Plus的配置类，确保@
MapperScan注解指定了正确的
mapper接口路径，以及实体类所在的包是否被正确扫描到。如果使用了多数据源，还需要确认各个数据源的配置是否正确，特别是实体类和
mapper的扫描路径是否没有冲突或遗漏。
接着检查依赖版本，查看
MyBatis-
Plus的官方文档，确认当前使用的版本是否
与项目中的其他依赖兼容。如果有必要，可以尝试升级或降级
MyBatis-
Plus的版本，看问题是否解决。
如果以上步骤都没有问题，可能需要深入调试，查看
MyBatis-
Plus在启动时的日志输出，确认是否有相关的错误信息。例如，是否在尝试解析实体类时抛出了异常，或者某些注解处理失败。通过启用DEBUG级别的日志，可以更详细地了解启动过程中发生了什么。
另外，还可以考虑编写一个简单的测试用例，创建一个新的实体类和对应的
mapper接口，验证是否能正常启动，从而确定问题是否特定于某个实体类或配置。如果新实体类没有问题，那么需要对比原有实体类和新实体类的差异，找出可能导致问题的部分。
最后，如果所有方法都尝试过仍然无法解决，可能需要查阅
MyBatis-
Plus的官方文档、GitHub的Issue页面，或者社区讨论，看看是否有其他开发者遇到过类似的问题，并参考他们的解决方案。如果问题依然存在，可能需要向社区提交Issue，提供详细的复现步骤和代码示例，寻求帮助。</think>遇到`
mybatis-
plus报because can not find cache of TableInfo for entity`错误时，通常是因为
MyBatis-
Plus无法正确解析实体类的元数据。以下是逐步排查和解决方案：
---
### **1. 检查实体类注解**
- **@TableName 注解缺失或错误**
确保实体类添加了`@TableName
("数据库表名"
)`注解。若数据库表名
与实体类名遵循驼峰转下划线规则（例如`UserInfo`→`user_info`），可省略该注解。
```java
@TableName
("sys_user"
) // 显式指定表名
public class User { ... }
```
- **字段
与列映射问题**
使用`@TableField
("column_name"
)`标注非驼峰命名的字段：
```java
@TableField
("user_name"
)
private String username;
```
---
### **2. 配置类扫描路径**
- **确保@
MapperScan指向
Mapper接口包**
在Spring Boot启动类或配置类中添加：
```java
@
MapperScan
("com.example.
mapper"
) // 替换为实际
Mapper接口路径
```
- **检查实体类包是否被扫描**
MyBatis-
Plus默认扫描启动类
同级目录及其子包。若实体类在其他
位置，需手动配置扫描路径：
```yaml
# application.yml
mybatis-
plus:
type-aliases-package: com.example.entity
```
---
### **3. 依赖版本冲突**
- **检查
MyBatis-
Plus版本兼容性**
确保依赖版本
与Spring Boot兼容。推荐使用最新稳定版：
```
xml
<!-- pom.
xml -->
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>
mybatis-
plus-boot-starter</artifactId>
<version>3.5.3.1</version>
</dependency>
```
---
### **4. 缓存问题**
- **清理并重建项目**
执行以下操作后重启应用：
1. Maven项目：`mvn clean install`
2. Gradle项目：`gradle clean build`
3. IDE：清理缓存（如IntelliJ的`File → Invalidate Caches`）
---
### **5. 复杂继承关系**
- **避免多级继承或接口继承**
MyBatis-
Plus可能无法解析多层继承的实体类。建议：
- 直接继承`Model<T>`类（若需使用AR模式）。
- 简化实体类结构，避免多态。
---
### **6. 调试
与日志**
- **启用DEBUG日志**
在`application.yml`中开启
MyBatis-
Plus日志：
```yaml
logging:
level:
com.baomidou.
mybatisplus: DEBUG
```
观察启动日志，确认是否抛出实体类解析异常。
---
### **7. 多数据源配置**
- **检查多数据源隔离**
若使用多数据源，确保每个数据源独立配置`@
MapperScan`，并指定`sqlSessionFactoryRef`：
```java
@
MapperScan
(basePackages = "com.example.
mapper.db1", sqlSessionFactoryRef = "db1SqlSessionFactory"
)
```
---
### **8. 示例代码验证**
创建一个最小化实体类和
Mapper进行测试：
```java
// 实体类
@TableName
("test_user"
)
public class TestUser {
@TableId
(type = IdType.AUTO
)
private Long id;
private String name;
}
//
Mapper接口
public interface TestUser
Mapper extends Base
Mapper<TestUser> {}
```
若测试通过，说明原项目存在特定实体类或配置问题。
---
### **总结**
通过以上步骤，90%的问题可定位到：
1. 注解缺失或错误 → 补充或修正注解。
2. 包扫描路径错误 → 调整`@
MapperScan`或配置。
3. 依赖冲突 → 升级/降级版本。
4. 缓存异常 → 清理重建项目。
若仍未解决，建议在[
MyBatis-
Plus GitHub Issues]
(https://github.com/baomidou/
mybatis-
plus/issues
)提交问题，附上实体类、配置及完整错误日志。
扫一扫
1806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
