继承mapper t 是报错

在使用MyBatis或MyBatisPlus进行开发时，经常会遇到一些因为继承关系导致的报错问题，在MyBatisPlus中，当我们使用泛型继承的方式来自定义Service层时，可能会遇到“Not Found TableInfoCache”的错误，这个错误通常发生在多继承的情况下，由于泛型解析的问题，导致无法正确识别实体类和Mapper接口。

我们需要理解错误发生的背景和原因，在MyBatisPlus中，ServiceImpl类提供了许多便捷的方法，如updateBatchById和saveBatch，这些方法能够让我们以更简洁的方式进行批量操作，当我们的Service层继承了一个或多个基类时，尤其是这些基类使用了泛型，就可能会出现TableInfoCache找不到的问题。

原因在于，MyBatisPlus内部通过反射机制来获取当前操作对应的实体类类型（entityClass）和Mapper接口类型（mapperClass），在多继承的情况下，如果基类的泛型参数没有被正确指定或者被覆盖，反射机制可能会错误地解析为java.lang.Object，而不是我们期望的实体类类型，这就导致了getTableInfo方法返回null，从而抛出“Not Found TableInfoCache”的错误。

为了解决这个问题，我们可以采取以下策略：

1、确保基类使用正确的泛型参数：如果我们的Service层继承了多个基类，需要确保所有的基类都使用了<M, T>这样的泛型参数，其中M代表Mapper接口，T代表实体类，这样，MyBatisPlus就能够正确地解析到实体类和Mapper信息。

2、：如果因为某些原因，我们不能改变基类的泛型参数，我们可以通过重写ServiceImpl中的currentModelClass和currentMapperClass方法来手动指定实体类和Mapper接口。

下面是一个示例：

public class CustomServiceImpl<M extends BaseMapper<T>, T> extends ServiceImpl<M, T> {
    @Override
    protected Class<T> currentModelClass() {
        // 手动指定实体类类型
        return (Class<T>) ReflectionKit.getSuperClassGenricType(getClass(), 1);
    }
    @Override
    protected Class<M> currentMapperClass() {
        // 手动指定Mapper接口类型
        return (Class<M>) ReflectionKit.getSuperClassGenricType(getClass(), 0);
    }
}

在这个示例中，ReflectionKit.getSuperClassGenricType方法来自MyBatisPlus工具类，它可以帮助我们获取到泛型参数的实际类型。

3、避免多继承导致的泛型冲突：如果可能，尽量避免在Service层进行多继承，如果确实需要，确保各个基类之间在泛型参数使用上不发生冲突。

4、检查实体类和Mapper的对应关系：有时，即使我们正确指定了泛型参数，但由于Mapper接口或实体类的位置或包发生了变化，也可能导致TableInfoCache找不到的问题，检查并确保Mapper接口和实体类的位置和包路径是正确的。

通过上述策略，我们通常可以解决因为继承关系导致的MyBatisPlus泛型解析错误，在解决这类问题时，理解MyBatisPlus内部的类型解析机制是很重要的，这样，即使遇到不同形式的错误，我们也能够根据原理找到相应的解决办法。

对于已经发生的错误，我们应该通过查看日志，仔细分析错误信息，确定错误的具体原因，在调整代码之后，务必进行全面的测试，确保修改后的代码能够稳定运行，不会影响到其他部分的业务逻辑，这样，我们才能确保在保证功能正确的同时，也保持了代码的健壮性。