php 8.2+ 支持 readonly 类，是类型契约起点；8.4 的 property hooks 解决读写不一致；8.5 的 |> 和 clone with 仅在特定场景省力，且各特性有严格版本边界。
readonly 类必须用 PHP 8.2+，但如果你还在用 8.3 或 8.4，别急着跳 8.5——8.4 的 property hooks 和非对称可见性已经能解决绝大多数 DTO 和领域对象的“读写不一致”问题；而 8.5 的 |> 管道操作符和 clone ($obj, [...]) 虽然清爽，却只在明确需要链式处理或只读对象微调时才真正省力。
readonly 类不是语法糖，是类型契约的起点
你写 readonly class UserDTO，就等于告诉 IDE、静态分析器（如 PHPStan）和协作者：“这个对象构造完就不能改”。它不光防误写，更让 $user->email 的类型在任何上下文中都稳定可推断——不会因为某处偷偷调了 setEmail() 就变成 mixed。
- PHP 8.2 引入，8.3/8.4/8.5 全支持，但 8.2 不支持
__construct参数解构赋值（如public string $name），得手动写$this->name = $name - 不能和
__set()或魔术方法共存；一旦声明readonly，所有属性自动public且不可重赋值 - 别试图在
readonly类里塞业务逻辑——它该是纯数据容器；验证、转换、副作用请交给工厂或服务类
property hooks 在 8.4 是“安全访问器”的默认选项
以前你要封装一个 email 属性，得配 private string $email + public function getEmail() + public function setEmail(string $email)，三处维护。现在直接：public string $email = '' { get { return trim($this->email); } set(string $value) { $this->email = filter_var($value, FILTER_SANITIZE_EMAIL); } }。
- 只在 PHP 8.4+ 可用；8.3 及以下会直接 Parse error
- hook 内部仍可访问
$this->email（backed property），但外部读写始终走 hook，不会绕过 - 注意性能：hook 里别做 heavy I/O 或复杂计算；如果只是格式化、trim、类型归一化，它比 getter/setter 更轻
管道操作符 |> 不是“函数式编程入场券”，而是减少临时变量的利器
|> 最适合处理一连串无状态变换，比如清洗输入、构建 URL、生成 slug。它不改变原值，也不要求函数必须返回相同类型——只要下一个函数能接收上一个的返回值就行。
- PHP 8.5 才支持，8.4 及以下用会报
Parse error: syntax error - 不能用于引用参数函数（如
sort(&$arr)），因为|>传递的是值拷贝 - 别硬套：如果中间步骤要复用、要加日志、要条件跳过，老老实实用临时变量或小函数更清晰
clone with 语法只对 readonly 类真正有用
clone ($dto, ['status' => 'draft']) 看起来方便，但它有个硬前提：目标类必须是 readonly。否则你本就可以直接赋值，根本不需要克隆。
- PHP 8.5 新增；8.4 及以下不识别
clone ($obj, [...])语法 - 只覆盖传入键名的属性；未指定的属性保持原值，包括其他
readonly字段 - 无法绕过
readonly保护——你不能用它去改一个非readonly类的私有属性
readonly 类，在 8.2+ 都能跑；但一旦混进 |> 或 clone ($obj, [...])，整文件就得锁死在 8.5；而 property hooks 是 8.4 独占，升级前得确认所有环境（CI、Docker、生产服务器）已统一。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
