php 8.1+ 使用 public readonly type $prop 声明只读属性，必须在构造函数中首次且仅赋值一次，引擎级强制不可变，不支持 static、嵌套只读或无类型声明。
PHP 8.1+ 怎么用 readonly 声明只读属性
PHP 本身没有“只读变量”概念，只有“只读属性”（readonly），且仅支持类属性，不能用于普通变量或函数内局部变量。它从 PHP 8.1 开始引入，底层是编译期强制约束，不是靠魔术方法模拟。
常见错误现象：Fatal error: Cannot assign to readonly property —— 这不是警告，是致命错误，一旦在构造函数外写入就崩。
-
readonly只能修饰类属性，语法为public readonly int $id; - 必须在构造函数中完成首次赋值，且只能赋一次；之后任何写操作（包括
$obj->prop = ...或反射）都会报错 - 不支持
static readonly，也不支持readonly数组元素或对象属性嵌套（如$obj->data->name不受保护） - 类型必须显式声明，不支持
mixed或无类型（PHP 8.2+ 允许readonly ?string，但依然要类型标注）
为什么不能用 __get/__set 模拟 readonly 属性
手动实现 getter/setter 看似灵活，但本质是运行时防护，绕过方式太多：反射、serialize/unserialize、直接改 $this->prop（如果没设为 private）、甚至数组强制转换都能破坏封装。
而 readonly 是引擎级保障，连反射都不能修改（ReflectionProperty::setValue() 会抛 TypeError）。
立即学习“PHP免费学习笔记（深入）”；
- __set 无法拦截
$obj->prop = ...对 public 属性的直接赋值（除非属性设为 private + 魔术方法，但 public readonly 就是为简化而生） - __get/__set 会带来性能开销，尤其高频访问场景；
readonly零额外成本 - IDE 和静态分析工具（如 PHPStan）能识别
readonly并提示误写，对魔术方法则基本无感知
readonly 属性在 DTO 和实体类中的典型用法
最适合用在数据传输对象（DTO）、值对象（VO）或不可变实体上，比如 API 返回的用户信息、数据库查询结果封装。
示例：
class UserDto
{
public function __construct(
public readonly string $name,
public readonly int $age,
public readonly ?string $email = null,
) {}
}
- 构造参数自动绑定到
readonly属性，省去手写赋值语句 - 允许默认值（如
?string），但注意：默认值不算“首次赋值”，仍需在构造时显式传入或由参数默认值触发 - 不要试图在构造函数体里再赋值：
$this->name = $name;是冗余且易错的（可能覆盖参数绑定） - 兼容性注意：PHP 8.0 及更早版本完全不识别
readonly关键字，会解析失败
readonly 和 const、final 的区别与误用场景
const 是类常量，属于类而非实例，所有实例共享；final 修饰类或方法，跟属性可变性无关；readonly 是每个实例独立持有的、初始化后不可变的属性。
- 别用
const存实例数据：比如const CREATED_AT = time();会报错，因为 const 必须是编译期常量 -
final class不影响内部属性是否可写，和readonly无关 - 误以为
private $x; final public function getX() { return $this->x; }就安全了——其实$x本身仍可被反射或序列化篡改 - PHP 8.2+ 支持
readonly class，表示整个类所有属性都隐式readonly，但目前仅限于没有构造函数的纯数据类（仍有诸多限制）
真正难处理的是嵌套可变性：一个 readonly 对象属性，其内部字段仍可被修改。比如 public readonly DateTime $createdAt;，你不能改 $dto->createdAt，但可以调 $dto->createdAt->modify('+1 day') —— 这种得靠设计约束或文档约定，语言层管不到。
