应该用public readonly属性，因其能防止意外修改、明确不可变语义，且Serializer默认支持；避免setter/getter冗余操作，严禁DTO混用Entity导致敏感泄露或循环引用。
DTO该不该用public readonly属性？
应该用，尤其是 Symfony 6.2+ 配合 #[MapRequestPayload] 时。readonly 属性能防止意外修改、明确数据不可变语义，且 Serializer 默认支持——只要 DTO 没有魔术方法副作用或构造依赖。
常见误操作是沿用传统 setter/getter 写法，结果在控制器里手动 new DTO 后又调用一堆 setXxx()，既冗余又破坏 DTO 的“传输契约”本质。
- ✅ 推荐：使用 PHP 8.2+
readonly class+ 构造参数直接赋值 - ❌ 避免：在 DTO 中定义
__construct()以外的逻辑（如数据库查询、事件触发） - ⚠️ 注意：
Serializer不会调用 setter，只读取 public 属性或 getter；若用 private 属性，必须配@SerializedName或@Groups注解
DTO和Entity混用会出什么问题？
直接把 Doctrine User 实体丢进响应返回，等于把数据库字段、关联关系、生命周期回调全暴露出去，轻则泄露敏感字段（比如 $passwordHash），重则触发循环引用导致 SerializationFailedException。
典型错误现象：API 返回空数组、500 错误、或嵌套 N 层用户地址再嵌套用户……
- ✅ 正确路径：Controller → Service → DTO（映射逻辑收口在 Service 或专用 Builder 类）
- ❌ 危险操作：
return $this->json($user);（$user是 Entity 实例） - ⚠️ 性能影响：未配置
@MaxDepth的 Entity 序列化可能加载整个关联图谱，一次请求拖垮 DB 和内存
怎么让 DTO 自动验证又不写重复代码？
Symfony 6.2 起，#[MapRequestPayload] 可以替代手写 $validator->validate()，前提是 DTO 带校验注解且控制器参数类型声明明确。
但要注意：它只对请求体（application/json）生效，不处理 query 参数或表单提交。
- ✅ 示例：DTO 中用
@Assert\NotBlank、@Assert\Email，控制器方法签名写public function create(#[MapRequestPayload] CreateUserDto $dto) - ❌ 错误写法：
public function create(Request $request)然后手动$request->toArray()再 new DTO —— 失去自动绑定和错误标准化 - ⚠️ 兼容性：PHP 8.0+ 才支持属性注解；若用 PHP 7.4，只能退回到传统
ValidatorInterface注入方式
DTO命名和目录结构怎么才不容易乱？
别叫 UserDto 这种模糊名字。DTO 是契约，命名必须体现场景和方向：输入还是输出？哪个接口用？
容易踩的坑是把所有 DTO 堆在 src/Dto/ 下，几个月后连自己都分不清 UserDto 到底是创建用还是列表返回用。
- ✅ 推荐结构：
src/Dto/User/CreateUserDto.php、src/Dto/User/UserResponseDto.php、src/Dto/User/UserCollectionDto.php - ✅ 命名规则：
[Domain][Action][Direction]Dto，例如ProductUpdateInputDto、OrderConfirmationOutputDto - ⚠️ 忽略这点的后果：改一个字段，得全局搜
UserDto，不敢动；加新接口时复制粘贴旧 DTO，字段语义悄悄漂移
