是。PHP DTO 必须手动声明属性和构造函数，因无原生 record 类型；需用 readonly 属性或 __get() 实现只读，映射时应显式转换类型并处理字段名差异，避免与 Resource/Normalizer 职责混淆。
PHP DTO 必须手动写属性和构造函数吗？
必须。PHP 没有原生的 record 类型或自动属性填充机制（PHP 8.2+ 的 readonly class 仅保证不可变，不自动生成构造器或属性赋值逻辑），所以 DTO 本质是一组显式声明的、只读（或有限可写）的属性 + 明确的初始化方式。
常见错误是试图用 stdClass 或 array 临时替代 DTO，结果在类型提示、IDE 支持、序列化一致性上出问题——比如传入一个缺失 user_id 的数组，运行时才报错，而 DTO 能在构造时就强制校验。
- 所有字段都应声明为
public readonly（PHP 8.1+）或private+public function __get()（兼容旧版） - 构造函数参数顺序必须与属性声明严格一致，避免靠注释“约定”顺序
- 不要在 DTO 中加业务逻辑方法（如
isValidEmail()），那是 Value Object 或 Domain Model 的职责
从数据库结果集（PDO/MySQLi）直接映射到 DTO 怎么做？
不能靠 json_decode(json_encode($row), true) 再 new UserDTO(...) —— 这会丢失类型、丢弃空字符串/0/false 等有效值，且无法处理字段名差异（如数据库用 created_at，DTO 属性叫 createdAt）。
推荐做法是写一个轻量映射函数，用数组键名映射控制转换过程：
立即学习“PHP免费学习笔记（深入）”；
function rowToUserDTO(array $row): UserDTO
{
return new UserDTO(
id: (int) $row['id'],
name: (string) $row['name'],
email: $row['email'] !== null ? (string) $row['email'] : null,
createdAt: new DateTimeImmutable($row['created_at'])
);
}
- 显式类型转换比依赖 PHP 自动转换更安全（例如防止
'0'被转成0后再被当成 false） - 对可能为
NULL的字段（如可空邮箱），先判空再 cast，避免DateTimeImmutable(null)报错 - 字段名不一致时，在映射函数里重命名，别让 DTO 属性迁就数据库命名
DTO 和 Laravel 的 Resource 或 Symfony 的 Normalizer 是什么关系？
DTO 是数据载体，Resource / Normalizer 是数据转换器——它们解决不同层次的问题。DTO 定义「我持有哪些字段」，Resource 定义「我怎么把 DTO 变成 JSON 响应」。
混淆这两者会导致 DTO 里塞进响应相关逻辑（比如 getAvatarUrlAttribute()），破坏单一职责。正确做法是保持 DTO 干净，把格式化逻辑交给外层：
- Laravel：在
UserResource中调用$this->resource->avatarPath，然后拼 URL；DTO 只存原始路径字段 - Symfony：用
NormalizerInterface实现normalize()，从 DTO 提取字段并添加额外结构（如嵌套_links） - 不要给 DTO 加
jsonSerialize()方法——这会让它同时承担数据定义和序列化职责
DTO 该不该实现 JsonSerializable 或 __toString()？
不该，除非你明确需要「DTO 实例能直接当 JSON 字符串用」且接受由此带来的耦合风险。
加 JsonSerializable 表面方便，实际埋坑：一旦 DTO 字段结构变化，所有依赖其 JSON 输出的地方都会静默受影响；__toString() 更危险——它暗示 DTO 可以被隐式转成字符串，但多数 DTO 根本没有唯一有意义的字符串表示（比如一个含 10 个字段的订单 DTO，toString 返回哪个字段？）。
- 需要 JSON 输出？用
json_encode($dto)即可（PHP 8.0+ 支持直接 encode readonly 对象） - 需要日志调试？用
var_export($dto, true)或封装一个debugInfo()方法 - 真要加
JsonSerializable，必须配合单元测试，确保每次变更字段都同步更新jsonSerialize()返回结构
