PHP readonly 类怎样避免配置对象被意外修改

如果配置对象创建后不应该再被调用方改写，PHP 的 readonly class 可以把这条约束直接放进类型定义：类中声明的属性只能初始化一次，同时不能临时塞入未声明的动态属性。对数据库连接参数、第三方服务地址、重试策略这类“读多写少”的对象，通常比只靠私有属性和约定更可靠。

官方地址：https://www.php.net/manual/en/language.oop5.basic.php

推荐的边界是：把配置值在构造函数中一次性整理好，用 readonly class 保护对象外壳；如果属性里还装着普通对象，则必须另外处理它的内部可变状态。readonly 解决的是“属性不能重新指向别的值”，不是所有嵌套数据的深度冻结。

先分清要保护的是配置字段还是整个对象图

以服务配置为例，endpoint、timeout、retries 是构造完成后应保持不变的值，这些就是直接资产。真正容易被忽略的是 headers、客户端实例等引用类型：外层属性不能改指向，但被引用的普通对象仍可能被内部修改。

endpoint;
?>

这里的“安全”指对象的三个声明属性不能再被重新赋值。它不等于地址一定可访问，也不替代 URL 校验、超时上限和密钥脱敏；这些仍应在构造函数或工厂方法中完成。

用 readonly class 一次收紧属性和对象形状

PHP 8.2 起，类声明前加上 readonly 后，类中每个声明属性都会带上 readonly 语义，并且不能创建动态属性。属性必须有类型，不能声明静态属性；子类若要继承，也必须继续声明为 readonly。

queue = 'logs'; // Error：不能修改 readonly 属性
// $config->region = 'cn'; // Error：readonly 类不能创建动态属性
?>

把约束写在类型上后，调用方不需要记住“不要改字段”这条隐含规则。需要扩展配置时，应新增构造参数或新建一个明确的配置类型，而不是在运行时临时添加字段。

初始化只能发生一次，作用域也不能绕开

readonly 属性必须是有类型的，并且只能从声明它的类作用域直接初始化。构造函数是最直观的入口；在全局作用域对尚未初始化的公开属性直接赋值，也会因为初始化作用域不对而失败。初始化完成后，即使写入相同的值也属于修改。

port = 587;       // Error：不能重新赋值
// $config->tls = true;       // Error：不能创建动态属性
?>

因此，配置变更应该表现为“创建一个新对象”，而不是修改旧对象。这个做法也让审计更简单：查找构造函数和工厂方法，就能找到配置进入系统的主要路径。

嵌套对象仍会变，克隆时要主动划清边界

readonly 保护的是属性槽位。若属性保存的是普通对象，调用方仍可能修改该对象的内部字段；这叫内部可变性。需要真正独立的配置快照时，可以在建模阶段使用不可变值对象，或在 PHP 8.3 及以上通过 __clone() 为 readonly 属性重新放入克隆后的对象。

retry = clone $this->retry;
    }
}

$original = new ClientConfig(new RetryPolicy(3));
$copy = clone $original;
// 修改副本的嵌套对象，不会指向原配置的同一个 RetryPolicy。
$copy->retry->maxAttempts = 5;
?>

如果项目仍需兼容 PHP 8.2，应在构造新实例时传入新的 RetryPolicy，不要使用 PHP 8.3 才提供的 clone 重初始化语义。反过来，如果配置字段只是标量或数组，readonly 已经足以阻止常见的重新赋值、数组追加、unset() 和引用传递修改。

上线前用这张清单检查配置对象

如果你的配置对象只是几项标量，readonly class 通常是低成本的保护措施；如果它包含连接、集合或第三方 SDK 对象，则应把“外层不可重新赋值”和“内部对象是否可变”分开设计。

相关问题

• readonly class 能否添加未声明的属性？不能，readonly 类会禁止动态属性。
• readonly 能否替代配置校验？不能，它只限制初始化后的修改，格式、范围和敏感信息处理仍要在构造阶段完成。
• PHP 8.2 怎样实现可独立修改的克隆配置？创建新配置对象并传入新建的嵌套对象；不要使用 PHP 8.3 才提供的 clone 重初始化能力。