PHP readonly 属性指向可变对象时边界是什么

PHP 的 readonly 只保证属性槽位初始化后不能再次绑定，它不会把槽位里保存的对象递归冻结。也就是说，$box->item = new Item() 会被拒绝，但 $box->item->name = 'new' 可能正常执行。真正要判断的是“引用不能换”还是“对象状态也不能变”。

官方手册：https://www.php.net/manual/en/language.oop5.properties.php

readonly 锁住属性槽位，但对象内部仍可能变化

先把“属性”和“属性值”分成两层看。属性保存的是对象句柄，readonly 约束的是这个句柄不能被换成另一个对象；它并没有替对象的公开方法和字段加锁。

user->name = 'new'; // 合法：修改对象内部字段

// 非法：readonly 属性已经初始化，不能重新绑定句柄
$profile->user = new User('other');
// Error: Cannot modify readonly property Profile::$user

这个例子适合解释“浅层只读”。如果 User 暴露了可写属性、可变数组或会改变自身的 方法，调用方仍能改变 Profile 间接持有的状态。想要真正的值对象，应让 User 自身不可变，例如私有字段配合返回新实例的更新方法，而不是只在外层加一个 readonly。

把初始化范围和间接修改列入检查

普通赋值之外，数组元素写入、递增、引用传递和 unset 也属于对只读属性的修改。未初始化属性只能在声明它的作用域中直接赋值，不能先取引用再写入。

flags = ['debug' => false];
    }

    public function enableDebug(): void
    {
        // 即使在类内部，也不能修改 readonly 数组的元素
        $this->flags['debug'] = true;
    }
}

数组和对象的表现不同：数组是值，元素修改会被视为修改属性本身；对象则是句柄，句柄不变时可以发生内部变化。排查异常时，先记录操作对象、操作类型和属性是否已初始化，不要只看“这一行是不是等号赋值”。

按业务目标设计更稳的只读封装

如果需求只是“构造后不允许替换依赖”，public readonly Logger $logger 已经足够；如果需求是“配置快照永远不变”，就不能把可变对象直接暴露出去。可以采用私有状态、只读访问器和返回新对象的 withXxx() 方法，把每次变化变成一次显式复制。

版本差异也要写进测试。PHP 8.3 允许在 __clone() 中重新初始化 readonly 属性，适合为克隆对象建立独立状态；PHP 8.4 以前 readonly 属性隐含 private set，8.4 起隐含 protected set，可由子类设置。它们都不是“对象自动深度不可变”的开关。

withValue('B');
// 断言对象身份和属性值都保持清晰的快照语义
assert($old->value === 'A');
assert($new->value === 'B');

验证清单很简单：测试重新绑定是否抛出 Error；测试对象内部字段是否仍能变化；测试数组、引用和 unset 的失败路径；最后在目标 PHP 版本测试克隆和继承写入。只有四项结果都符合预期，才能说封装边界被验证过。

相关问题

readonly 对象属性等于深度不可变吗？

不等于。它限制属性槽位的重新赋值；对象内部字段、集合和资源的状态仍由对象自身的接口决定。

为什么 readonly 数组元素不能修改？

数组是属性值本身，写入元素就是修改该值；对象则通过句柄间接指向独立的内部状态。

PHP 8.3 的 clone 规则解决了什么问题？

它允许克隆阶段为新实例重新初始化 readonly 属性，便于复制后建立独立快照，但不会替你深拷贝所有嵌套对象。

什么时候不该只靠 readonly？

当业务要求审计快照、跨线程或跨请求共享的稳定状态时，应把内部字段设为私有，并通过返回新实例或显式复制来实现对象级不可变。