应选EntityType当选项需绑定数据库实体并自动转换为托管对象，选ChoiceType当仅需字符串/数字枚举值；前者依赖Doctrine管理状态，后者轻量无ORM耦合。
EntityType 和 ChoiceType 该选哪个
选 EntityType 还是 ChoiceType，取决于选项数据来源是否绑定数据库实体。不是看“要不要下拉”，而是看“值要不要自动转成对象”。
EntityType 本质是为关联实体设计的：提交 ID，自动查出对应托管实体；ChoiceType 只负责渲染和校验字符串或数字，不碰 Doctrine。
- 要让表单字段直接接收一个
Author对象（比如用于$post->setAuthor($author)），必须用EntityType - 只是存个状态码（如
status = 'active'）或枚举值，ChoiceType更轻、更可控、无 EntityManager 依赖 - 强行用
EntityType渲染非实体数据（比如硬写choices数组），会触发 “Class not found” 或 “No identifier defined” 错误
EntityType 的 class 和 choice_label 怎么配才不报错
class 必须是已映射的 Doctrine 实体类名（如 App\Entity\User），且该类必须有主键（@ORM\Id）。choice_label 决定下拉里显示什么，但它不能随便写——它得能从实体实例上安全读取。
- 写字符串（如
'fullName'）：要求实体有 public 属性$fullName，或有 getter 方法getFullName()/isFullName() - 写回调函数：必须返回字符串，且不能抛异常（比如
choice_label => fn($user) => $user->getName() ?? ''） - 写表达式（如
'name ~ " (" ~ email)'）：需启用 Twig 表达式语法，且字段必须可访问（protected/private 字段需有 getter） - 如果
choice_label指向不存在的属性或方法，渲染时抛UnexpectedValueException，错误信息含 “The option "choice_label" is invalid.”
默认值传给 EntityType 为什么总提示 “must be managed”
这个错误几乎都来自把“分离态”实体（detached entity）直接塞进 data 选项。典型场景：从 session 取出的实体、手动 new 出来的实体、或没 flush 过的新对象。
-
data选项只接受“托管实体”（managed entity）——即被当前EntityManager跟踪的对象 - 从 session 拿到的是反序列化后的分离对象，必须用
$em->getReference()或$em->find()重新加载 - 正确做法：
'data' => $em->find(User::class, $userIdFromSession)，而不是'data' => $userFromSession - 如果只是想设个初始 ID 值（不强求对象），改用
empty_data+data_class组合，绕过对象绑定逻辑
ChoiceType 的 choices 数组怎么避免类型混乱
choices 是键值对数组，但 Symfony 对“键”和“值”的处理逻辑完全不同：键用于展示（HTML <option></option> 文本），值用于提交（POST 数据）。很多人混淆这两者，导致前端显示对、后端收不到或类型错乱。
- 值（数组 value）可以是字符串、整数、布尔，甚至
null；Symfony 自动做类型转换，但integer值提交后仍是 int，"1"是 string —— 验证器和数据库字段类型必须匹配 - 键（数组 key）仅用于渲染，支持翻译域，但若关闭
choice_translation_domain，就按原样输出；别在 key 里写 HTML 或特殊字符，否则渲染出错 - 多选场景下，
multiple => true时，提交数据是数组，控制器里接收参数必须声明为array类型，否则TypeError - 动态生成
choices（比如从 DB 查）时，别在表单类里直接调用$em->getRepository()；应通过query_builder（EntityType）或预加载后传入选项（ChoiceType）
