Spring Data父类标注@Document时子类能否重写覆盖该注解？

Spring Data MongoDB 对@Document注解的映射逻辑和常规注解继承认知有差异，核心规则如下：

• @Document本身未标记@Inherited元注解，语法层面子类声明的@Document不会被父类注解覆盖，但框架初始化MongoMappingContext缓存实体元数据时，会优先取继承链上首个标注@Document的类作为根实体，绑定对应的集合名、字段映射关系。
• 如果子类没有定义任何额外字段、没有重写父类属性，框架会直接复用父类的缓存元数据，完全忽略子类上的@Document配置，这就是所有查询都路由到original_collection的直接原因。
• 额外注意：如果DAO层Repository接口的泛型参数指定为父类类型，即使查询时传入子类对象，也会默认使用父类绑定的集合名。

方案1：抽离无注解公共基类（推荐） #

这是兼容性最好、最符合框架设计逻辑的实现方式，不需要修改任何查询逻辑：

1. 将原有带@Document的父类改为抽象基类，移除类上的@Document注解，仅保留所有公共字段、通用方法定义。
2. 业务主集合对应实体类继承基类，单独标注@Document("original_collection")，无额外字段时空类即可。
3. 归档集合对应实体类继承基类，单独标注@Document("archived_collection")，无额外字段时空类即可。
   代码示例：

// 公共基类，不配置@Document，仅存公共属性
public abstract class BaseBizObject {
    private String id;
    private String status;
    private LocalDateTime createTime;
    private LocalDateTime updateTime;
    // 公共getter/setter、通用方法省略
}

// 业务主集合实体
@Document("original_collection")
public class BizObject extends BaseBizObject {}

// 归档集合实体
@Document("archived_collection")
public class ArchivedBizObject extends BaseBizObject {}

该写法下两个实体的映射元数据完全独立，框架不会出现集合名复用的问题，同名字段可以正常完成序列化/反序列化。

方案2：查询时显式指定集合名 #

如果不想调整现有实体类的继承结构，直接在调用MongoTemplate时手动传入目标集合名即可，该参数优先级高于实体类注解配置，会直接覆盖自动解析结果：

// 查询归档集合
List<ArchivedBizObject> archivedList = mongoTemplate.find(
        Query.query(Criteria.where("status").in("Archived", "Discarded")),
        ArchivedBizObject.class,
        "archived_collection"
);

// 查询业务主集合
List<BizObject> bizList = mongoTemplate.find(
        Query.query(Criteria.where("status").in("Published", "Unmapped")),
        BizObject.class,
        "original_collection"
);

方案3：独立定义Repository接口 #

如果使用Spring Data MongoDB的Repository抽象做数据访问，不要在公共父类上定义泛型为基类的通用Repository，需要为两个实体分别声明独立的Repository接口：

public interface BizObjectRepository extends MongoRepository<BizObject, String> {}
public interface ArchivedBizObjectRepository extends MongoRepository<ArchivedBizObject, String> {}

直接注入对应Repository调用查询方法，框架会自动路由到实体绑定的集合。

• 不要给两个同结构实体配置相同的@TypeAlias值，否则反序列化时会出现类型转换异常。
• 不推荐通过自定义集合名解析器实现该需求，会增加不必要的框架复杂度，后续维护成本高。

内容的提问来源于stack exchange，提问作者Asad Nawaz