doctrine继承映射需选对策略：单表适合字段少、跨类型查询；类表适合差异大、需数据隔离；具体表不推荐。配置须匹配php属性语法，api platform中子类需单独标注apiresource，查询基类仅单表有效。
Doctrine继承映射不是“能不能用”，而是“选哪种策略、怎么配对、哪里容易断链”。核心在于匹配实体定义方式（PHP属性 or 注解）、继承结构语义，以及数据库读写效率需求。用错一种，轻则查询报错 Class ... is not a valid entity，重则数据混杂、API返回异常。
先选继承策略：看业务变与不变
Doctrine支持三种主流策略，适用场景差异明显：
-
单表继承（SINGLE_TABLE）：所有子类共用一张表，靠
discriminator_column字段区分类型。适合子类字段少、查询频繁跨类型（比如Article和Comment都要列表展示）、且不介意空字段占用空间。 -
类表继承（JOINED）：父类一张表存公共字段，每个子类一张表存特有字段，通过外键关联。适合子类差异大、字段多、且需要严格数据隔离（比如
Person和Organization共享id和created_at，但各自有完全不同的扩展字段）。 - 具体表继承（CONCRETE）：每个子类一张完整表（含父类字段），无共享表。Doctrine支持有限，不推荐；若真需要，建议改用组合或视图替代。
配置必须和代码写法一致
PHP 8+ 项目默认用 #[ORM\Entity] 这类属性（attributes），但 Doctrine 配置文件里如果还写着 type: annotation，就会彻底找不到实体——这是最常导致 not a valid entity 错误的原因。
检查并修正 config/packages/doctrine.yaml：
doctrine:
orm:
mappings:
App:
type: attribute # ← 必须是 attribute，不是 annotation
dir: '%kernel.project_dir%/src/Entity'
prefix: 'App\Entity'
同时确保所有类都用了属性语法，例如：
#[ORM\Entity]
#[ORM\InheritanceType('JOINED')]
#[ORM\DiscriminatorColumn(name: 'type', type: 'string')]
#[ORM\DiscriminatorMap([
'person' => Person::class,
'org' => Organization::class,
])]
abstract class Party { }
API Platform中暴露继承实体
在 API Platform 中，只要实体被正确识别为 Doctrine Entity，它就能自动生成对应端点。但要注意两点：
- 每个具体子类（如
Person、Organization）都要加#[ApiResource]，否则不会注册路由； - 基类（
Party）通常设为abstract且不加#[ApiResource]，避免暴露无意义的通用接口； - 如果要用
GET /api/parties返回多态集合（混合person和org），需确保序列化器能处理 discriminator 字段，或手动配置normalization_context显式包含type。
别让控制器和存储库踩坑
继承结构下，控制器和存储库行为会受策略影响：
- 查子类时，用
$this->getDoctrine()->getRepository(Person::class)没问题；但查基类（如Party::class）只在单表继承下才返回混合结果，类表继承下会报错或为空； - 自定义存储库方法要写在基类 Repository（如
PartyRepository）里，并确保 DQL 查询显式 join 子类表（类表继承）或过滤 discriminator（单表）； - Symfony 控制器无需特殊继承，
AbstractController照常可用，但注意$this->getDoctrine()->getManager()返回的是标准 EntityManager，不感知继承逻辑。
