PHP 8.5 clone with 怎么改不可变对象：属性覆盖、私有属性与回归检查

订单查询接口里有一个很常见的对象：先读出一份筛选条件，再只改页码或状态，重新发起下一次查询。以前通常要写一个 withPage() 方法，或者先复制对象再手动赋值。PHP 8.5 的 clone with 把这段动作收进了克隆表达式，特别适合保持原对象不变的 DTO、查询条件和配置对象。

PHP 8.5 的 clone with 到底省掉了什么

先看一个不可变查询条件对象。它的职责很简单：保存筛选条件，提供一份新条件，而不是让调用方在原对象上反复改值。

page);  // 1
var_dump($secondPage->page); // 2

$firstPage 没有被改写，$secondPage 是一个新对象。这个差异对缓存键、重试逻辑和并发请求很重要：每个请求拿到自己的条件，不会因为共享对象被后续代码悄悄改动。

最小配方：公开属性、类型和默认值一起验收

写法的关键不是把所有属性都暴露出来，而是只开放那些确实适合在复制时变化的字段。页码、排序方向这类请求级参数可以公开；租户 ID、签名或权限范围则不应让调用方任意替换。

这里的“公开属性”说的是访问边界，不是业务安全边界。即使语法允许覆盖，也要问一句：改完后对象还满足自己的约束吗？

把校验放在对象边界：不要让 clone with 变成隐形 setter

例如页码不能小于 1，状态只能来自白名单。可以让构造函数负责第一次创建，再在 __clone() 或专门的复制方法中维护相同规则。不要因为表达式变短，就把校验移到每个调用点。

state, $this->page + 1);
    }
}

$query = new ReportQuery('open');
$next = $query->nextPage();

这类方法在 PHP 8.4 及更早版本也能工作，所以它是很实用的兼容层。项目切到 PHP 8.5 后，再把适合的简单字段改成 clone with，不要一次性重写所有对象复制逻辑。

私有属性、__clone() 与旧版本兼容，三个坑要提前看

私有属性不能当成跨类的快捷通道

私有字段通常承载对象不变量。调用方如果需要改变它，应调用类提供的命名方法，或者让类自己实现一个带校验的复制入口。这样未来调整字段名时，业务代码不会到处依赖内部布局。

__clone() 里的副作用要重新检查

如果类实现了 __clone()，复制时可能会重置数组、清理临时句柄，甚至生成新的关联对象。升级后不要只看返回值，还要确认克隆动作没有重复写日志、重复注册资源或共享本不该共享的引用。

PHP 8.4 或更早版本无法直接解析新语法

clone with 属于语法级能力，旧运行时连文件解析都可能失败。公共 Composer 包或多版本部署项目，要么提高平台约束，要么把新写法隔离在 PHP 8.5 专用文件中，并继续使用工厂方法作为降级路径。

升级后的回归检查清单

1. 用目标 PHP 8.5 运行最小样例，确认原对象和新对象的字段值分别符合预期。
2. 给覆盖字段传入错误类型、越界值和非法枚举值，确认失败位置仍在对象边界。
3. 检查私有属性、嵌套对象、数组引用和 __clone() 是否出现意外共享或重复副作用。
4. 用 CI 的最低支持版本执行语法检查，避免把 PHP 8.5 文件带入旧运行环境。
5. 对缓存键、序列化结果和审计日志做一次差异比对，确认“复制并覆盖”没有改变业务身份。

常见问题

clone with 会修改原对象吗？

不会。它的意图是先生成克隆对象，再对克隆对象应用覆盖值；原对象仍可继续用于原来的请求或缓存场景。

所有属性都适合用 clone with 覆盖吗？

不适合。权限、租户、对象身份和派生字段通常应由类内部维护，公开可变的筛选条件才适合直接覆盖。

PHP 8.4 项目能直接使用这段语法吗？

不能把它当作普通库函数兼容。先确认运行时版本；需要支持旧版本时，保留构造函数、工厂或 withXxx() 方法作为替代实现。

为什么用了 readonly 还要写回归测试？

readonly 只表达属性写入边界，不能替代类型、范围、引用关系和克隆副作用检查。升级语法后，这些行为仍应由测试锁定。

如果一个对象只是保存几项请求参数，clone with 能让“复制一份再改一项”更接近业务意图；如果对象内部有复杂资源或强不变量，保留命名复制方法通常更稳。先按边界选择写法，再考虑语法是否更短。