只读属性适用于dto和值对象，确保状态不可变；配置类必须使用以防止运行时污染；实体类应避免滥用，因其需orm管理生命周期；反序列化需手动校验以保障安全。
只读属性适合 DTO 和值对象封装
DTO（数据传输对象）和值对象（Value Object）是只读属性最自然的落点。这类对象的核心语义是「携带数据、不承载行为、状态不可变」，比如 UserProfile、Money、Coordinates。一旦构造完成，修改字段就违背其设计意图。
用 readonly 显式声明，能从语言层阻止误赋值，比靠文档或约定更可靠。尤其在 API 响应组装、领域模型传递、跨服务序列化时，避免下游意外篡改原始数据。
- DTO 场景下，
public readonly属性可直接暴露，省去 getter 方法，又不失安全性 - 值对象常需重载
==或实现__toString()，只读性保障了哈希/比较逻辑的稳定性 - 配合 PHP 8.3 的默认值语法（如
public readonly string $status = 'pending';），可减少构造函数参数膨胀
配置类必须用 readonly 防止运行时污染
配置对象（如 DatabaseConfig、ApiSettings）一旦加载完成，就不该被业务代码动态修改。否则容易引发并发问题、环境错乱或调试困难——比如某个中间件悄悄改了 $config->timeout，后续请求全部超时。
只读属性在这里不是“锦上添花”，而是兜底机制。即使开发者忘了加 private 或漏写 setter 保护，readonly 也能在运行时报错，而不是静默失败。
- 推荐搭配
final class使用，彻底禁止继承和覆盖 - 避免在构造函数外初始化：只读属性必须在
__construct()执行结束前完成赋值，否则会触发Fatal error: Uninitialized readonly property - PHP 8.3 支持数组默认值（如
public readonly array $whitelist = ['admin', 'user'];），但注意不能放对象实例
避免在实体类（Entity）中滥用 readonly
ORM 实体（如 UserEntity）通常需要持久化生命周期管理：数据库回填 ID、时间戳自动更新、关系对象懒加载等。这些操作本质是「合法的内部状态变更」，而 readonly 会直接拦截，导致 Cannot modify readonly property 错误。
哪怕你把所有属性都设为 private readonly，ORM 框架（如 Doctrine、Eloquent）也无法绕过语言限制写入数据。这不是框架缺陷，而是语义冲突。
- 实体类更适合用
private+ 显式 setter 控制修改入口，或依赖 ORM 自身的生命周期钩子 - 若真想约束字段不可变，可拆出只读 DTO 层（如
UserDto），由实体映射生成，而非让实体自己 readonly - 别试图用反射绕过
readonly—— PHP 8.2+ 已禁止反射修改只读属性，ReflectionProperty::setValue()会抛出Error
只读属性与序列化/反序列化的兼容边界
serialize() 和 unserialize() 能正常处理只读属性，但要注意：反序列化过程不经过构造函数，PHP 会跳过只读检查直接填充属性值。这看似方便，实则埋雷。
例如一个 readonly int $id 在反序列化时被填入 0，而它本应由数据库生成；或者一个 readonly DateTimeImmutable $createdAt 被反序列化成非对象值，后续调用 format() 就崩了。
- PHP 8.3 开始，反序列化只读属性时若类型不匹配（如期望对象却给了字符串），会触发
TypeError，但不会阻止赋值本身 - 安全做法是实现
__unserialize()，手动校验并重建只读属性，而非依赖自动填充 - JSON 序列化（
json_encode()）不受影响，但反序列化（json_decode()）生成的是普通 stdClass，无法直接转成只读类实例
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
