serializerinterface注入失败主因是framework.yaml未启用serializer：true；symfony 6.2+默认关闭，需手动开启，否则运行时报servicenotfoundexception且序列化必失败。
SerializerInterface 注入失败，先查 framework.yaml 是否启用
直接报 ServiceNotFoundException？大概率是组件根本没启用。Symfony 6.2+ 默认关闭 Serializer，哪怕装了 symfony/framework-bundle 也不代表它就可用。
打开 config/packages/framework.yaml，确认存在：
framework:
serializer: true
API Platform 会自动启用，但别假设它一定在——尤其项目里混用旧版 FOSRestBundle 时，它可能悄悄覆盖了服务定义。
没启用就注入 SerializerInterface，运行时必挂；就算手动 new Serializer 类，也会因缺 Normalizer（比如 ObjectNormalizer）而抛 Call to undefined method …::getClassName()。
序列化空数组或 null，检查传入对象类型和访问控制
输出是空的，不是 JSON 错误，而是 Serializer 根本没读到字段。常见原因有两个：
- 传了不安全的对象：比如
$request、$entityManager、含闭包/资源句柄的 Doctrine 实体 —— 这些会静默失败或抛SerializationFailedException - DTO 或实体字段不可见：private 属性没配 getter，也没加
#[Groups]或#[SerializedName]，ObjectNormalizer默认只读 public 属性或 getXXX()/isXXX() 方法
安全输入类型只有这些：array、stdClass、无构造依赖的 DTO、实现了标准 getter 的 POPO。
DateTimeImmutable 要确保 DateTimeNormalizer 已加载（默认启用），否则也容易返回空。
Doctrine 实体嵌套序列化时爆栈或字段过多
User → Post → User 这种循环引用，不处理就会触发 CircularReferenceException 或无限递归。别指望靠全局 access_type: property 解决——它破坏封装，还可能暴露敏感字段。
正确做法是组合使用：
-
#[Groups(['user:read'])]控制主实体字段 -
#[Groups(['post:id_only'])]单独定义关联实体的最小输出组 -
#[MaxDepth(1)]加在关联属性上，硬性截断嵌套层级 - 调用时显式传上下文：
$serializer->serialize($user, 'json', ['groups' => ['user:read']])
注意：不同关联关系（如 OneToMany vs ManyToOne）对 @MaxDepth 的生效位置不同，得看实际对象图走向，不是加在主实体上就万事大吉。
JSON 输出字段名是 camelCase，但前端要 snake_case
不用改 PHP 属性名，Serializer 自带名称转换器。在 config/packages/framework.yaml 里加配置：
framework:
serializer:
name_converter: 'serializer.name_converter.camel_case_to_snake_case'
它会影响所有用 ObjectNormalizer 的场景，包括 #[Groups] 生效的字段。
如果只想局部生效，比如只对某个 DTO 用 snake_case，就得自定义 NameConverterInterface 实现，并在构造 ObjectNormalizer 时传入——但绝大多数项目直接全局配更省事。
这个转换器不改变注解里的 #[SerializedName('user_name')]，后者优先级更高，会直接覆盖名称转换逻辑。
