Hyperf 3.0 不支持 PHP 8.2 readonly 类自动适配，DI 容器、验证器、序列化器等默认按普通类处理，直接使用会导致“Uninitialized readonly property”等致命错误；正确做法是禁用隐式实例化，统一通过带参数校验的工厂函数创建只读 DTO 实例。
Hyperf 3.0 本身不提供对 PHP 8.2 readonly 类的特殊支持或自动适配，所有只读类行为完全由 PHP 引擎强制执行；Hyperf 的 DI 容器、验证器、序列化组件等默认按“普通类”逻辑工作，直接与 readonly 类配合会高频触发 Fatal error: Uninitialized readonly property 或 Error: Cannot modify readonly property。
Hyperf DI 容器无法直接 make 只读 DTO
Hyperf 的 $container->get(UserDTO::class) 或 app()->get(UserDTO::class) 默认尝试无参构造或类型自动注入，而 readonly 类禁止空对象创建 —— 这会导致运行时立即崩溃。
- 错误现象：
Fatal error: Uninitialized readonly property UserDTO::$email - 根本原因：容器未传入任何构造参数，PHP 拒绝初始化只读属性
- 不能靠
@Inject或@Value注解补全，这些只作用于属性赋值，不经过__construct() - 正确做法：禁用容器直接实例化只读类，改用工厂函数手动传参
Hyperf 验证器（Validation）需绕过自动 new
Hyperf 的 ValidatorFactory 默认调用 new $class(...) 实例化 DTO，若传参不全（如漏掉 ?string 字段），就会在验证前就报错，验证逻辑根本没机会执行。
- 常见错误：
validate($request->all(), UserDTO::class)→ 数组缺键即崩 - 验证器不负责字段兜底，它只校验已有数据；而只读类要求“所有字段必须显式传入”，包括
null - 解决方案：先用工厂函数做数组预处理（
array_key_exists校验 + 缺失字段补null），再把完整数组交给验证器 - 示例：
makeUserDto($request->all())工厂内部已确保$email必存在（哪怕为null），验证器才安全介入
Hyperf 序列化/反序列化需显式控制
Hyperf 默认使用 json_encode/json_decode，但 json_decode($json, true) 返回数组，无法直接喂给只读类构造函数；若用 json_decode($json, false) 得到 stdClass，属性名不匹配、类型不对、可空字段缺失等问题会立刻暴露。
立即学习“PHP免费学习笔记（深入）”；
- 错误写法：
new UserDTO(...(array) json_decode($json))→ 键名可能不一致，stdClass属性不可访问 - 推荐路径：统一走
makeUserDto(json_decode($json, true))工厂，由工厂做键映射、类型转换、空值归一化 - 注意：只读类不拦截
unserialize()，但 Hyerf 的Serializer组件若尝试反射设属性，会直接抛Error: Cannot modify readonly property - 安全做法：禁用自动反序列化只读类，所有 JSON 输入必须经工厂中转
Hyperf 测试中 mock 只读类会失败
Hyperf 常用的 Mockery::mock(UserDTO::class) 或 $this->createMock(UserDTO::class) 在 PHP 8.2 下直接 fatal —— Mockery 依赖反射创建空对象再设属性，这被只读类语法层硬性禁止。
- 错误信息：
Fatal error: Cannot initialize readonly property ... via reflection - 替代方案：测试中不 mock 只读 DTO，改用真实 fixture 数组 + 工厂函数生成实例
- 例如：
$dto = makeUserDto(['id' => 'u1', 'email' => 'a@b.c', 'nickname' => null]); - 若 DTO 构造逻辑复杂，把校验和转换抽成独立 service，只对 service 单测，DTO 保持极简纯数据载体
只读类在 Hyperf 中不是“开箱即用”的增强特性，而是需要你主动切断所有隐式构造路径——DI 容器、验证器、序列化器、Mock 工具，它们默认行为都与只读约束冲突；真正的优化点只有一个：把所有对象创建收口到显式、可控、带校验的工厂函数里，否则任何一处疏漏都会在运行时炸开。
