PHP 8.4：当 readonly 变身“物理锁甲”——一场对抗 FFI 的深潜
大家好！欢迎来到今晚的“深蓝代码研讨会”。我是你们的主讲人，一个已经在 PHP 核心底层摸爬滚打了十年的“老油条”。
今天我们不聊简单的循环，也不聊怎么让 foreach 变得更快。今天，我们要聊聊安全。具体来说，我们要聊聊 PHP 8.4 中一个令人兴奋、甚至可以说是“硬核”的功能：readonly 类属性的物理加固。
在此之前，如果你问我 PHP 的 readonly 是什么，我会告诉你：“它就是一个语法糖，用来告诉编译器‘嘿，这玩意儿赋值了一次之后，别再动它’。” 如果你问我它能防住什么，我会告诉你：“它防得住程序员手滑，防得住那个喝醉了酒的实习生，但防不住一个拿着 C 指针、眼冒绿光的黑客。”
今天，PHP 8.4 的到来，彻底改变了这一局面。它不再是虚弱的“橡皮图章”，而是变成了坚不可摧的“物理锁甲”。
让我们把时钟拨回到那个“弱不禁风”的旧时代，看看我们到底是怎么被 FFI 霸凌的。
第一幕：被 FFI 欺负的“伪君子”
在 PHP 8.3 及以前，readonly 属性就像是一个挂在门把手上的锁。它看起来像个锁，但其实它只是一个标签。只要你拿到了这把锁的钥匙（对象引用 $this），你就可以随时把标签撕掉，或者把里面的东西换掉。
这听起来很可怕，对吧？我们来演示一下。假设我们有一个代表银行账户的类，我们要确保这个余额在初始化之后不能变。我们天真地写下了这样的代码：
<?php
class BankAccount
{
// 我们想保护这个余额
public readonly int $balance;
public function __construct(int $initialBalance)
{
$this->balance = $initialBalance;
}
}现在，这个账户余额是 100。我们对它充满了信心。但是，作为一名资深专家，我知道这所谓的“不可变”，在 FFI 面前就像一张薄纸。
FFI，全称是 Foreign Function Interface（外部函数接口）。它允许 PHP 直接调用 C 代码，甚至直接操作内存地址。对于一个懂行的黑客来说，PHP 对象在内存中是什么样的？它是一个结构体（struct）。属性在哪里？在对象的哈希表（HashTable）里。
黑客会写一个 C 扩展，或者直接用 FFI 库，做以下几件事：
- 找到你的
BankAccount对象在内存中的地址。 - 定位到
$balance这个属性的偏移量。 - 使用
memcpy或者直接修改内存指针，把 100 改成 999999999。
这就好比你在房间里放了一个保险箱，贴了一张纸写着“内有巨款，严禁动用”。然后你告诉所有人：“看，它是锁着的！” 但实际上，门没锁，甚至保险箱的盖子都是敞开的，只差一个黑客走过去把钞票拿走。
这就是 PHP 8.3 以前 readonly 的本质。它是一个逻辑约束，而不是物理约束。
第二幕：内存解剖课——为什么以前的 readonly 不靠谱？
为了理解 PHP 8.4 的升级，我们需要深入到底层，看看 PHP 对象在内存里到底长什么样。
在 PHP 的世界（ZVAL）里，一个变量通常包含两部分：类型和值。
对于普通对象，属性并不直接保存在对象结构体里，而是保存在一个独立的哈希表中。这个哈希表就像是一个庞大的 Excel 表格，每一行记录一个属性名（如 $balance）和一个对应的 Zval。
当你给一个属性赋值 readonly 时，PHP 只是在这个 Zval 的类型信息里打了一个标记，告诉引擎：“嘿，我赋过值了，别让我再赋值。”
但是！ 这个 Zval 还在哈希表里。这个哈希表还在内存里。这就给了 FFI 立足之地。只要 FFI 知道对象的起始地址、知道属性名对应的哈希值、知道属性在表中的偏移量，它就可以直接跳进去，把那个标记改掉，或者把里面的值覆盖掉。
这就好比你在一个巨大的仓库里放了一个箱子，并在箱子上贴了个“仅限查看”的标签。黑客只要溜进仓库，找到那个箱子，把标签撕了，换上“开放”的标签，甚至把里面的金条换成砖头。
第三幕：PHP 8.4 的“物理”打击
好，重头戏来了。PHP 8.4 引入了一个概念，我们称之为readonly 属性的物理锁定。
这到底是什么意思？
简单来说，PHP 8.4 改变了 readonly 属性的存储方式。在 PHP 8.4 中，如果一个属性被声明为 readonly，并且使用了构造函数参数属性提升（Constructor Property Promotion），那么这个属性将不再被存储在哈希表中，而是被物理地内联到对象的结构体本身之中。
这就像什么？这就像你不再把东西放在仓库里，而是把金条熔铸成了桌腿，直接嵌入到你的桌子（对象）里。你想改金条？对不起，桌子已经连成一体的实体了。
1. 新的语法限制：构造函数的特权
为了实现这种物理锁定，PHP 8.4 对 readonly 属性的使用施加了极其严格的限制。在 8.4 版本中，你只能在构造函数中对 readonly 属性进行初始化赋值。
如果不在构造函数里赋值，哪怕你在方法里、静态变量里，甚至在其他地方赋值，PHP 都会直接报错。
<?php
class SafeAccount
{
// PHP 8.4: readonly 属性必须由构造函数初始化
public readonly int $balance;
public function __construct(int $initialBalance)
{
// 这里是赋值的唯一合法场所
$this->balance = $initialBalance;
}
// 以下代码在 PHP 8.4 中将直接导致致命错误 (Fatal Error)
// public function doSomething() {
// $this->balance = 999; // 错误！这不再是逻辑检查，这是语法禁止！
// }
}这不仅是限制了赋值，它彻底改变了 readonly 的生命周期。它不再是对象创建后不可变，而是从出生那一刻起，它就是一个不可变的常量。
2. FFI 的噩梦
现在，让我们回到 FFI 黑客的世界。PHP 8.4 改变了对象在内存中的布局。
在旧版本中，黑客需要：
- 拿到对象地址。
- 计算 Hash 值。
- 遍历 Hash Table 找到偏移量。
在 PHP 8.4 中，使用了 PPH（构造函数参数属性提升）的 readonly 属性，其值被直接存储在对象结构体的 Zval 中，而不是在动态哈希表里。
这意味着 FFI 再也不能通过“查找属性名”的方式去修改这个值了。因为 FFI 不知道这个属性具体藏在内存的哪个字节里（除非它去解析 PHP 8.4 的源码和结构体定义，但那已经超出了常规脚本的范围）。
即使是一个用 C 写的扩展，试图通过 zend_object 的标准方法去操作属性，也会发现那个 readonly 标志位不再只是一个标记，它变成了一堵墙。修改它会导致 PHP 内部核心错误，因为你在试图修改一个“物理锁定”的值。
第四幕：实战演示——FFI 试图篡改
为了证明这一点，我们需要动用一点“黑魔法”。虽然我们不能在这里真的编译一个 C 扩展（太长了），但我们可以用 PHP 8.4 的 FFI 库来模拟这种攻击的思路，并展示防御机制。
假设我们有一个 PHP 8.4 的脚本：
<?php
// 定义一个模拟的 C 结构体，对应 PHP 8.4 中的对象布局（概念上）
// 注意：这只是为了演示，真实的 Zend 内部结构更复杂
$ffi = FFI::cdef("
typedef struct {
int64_t readonly_value; // 假设我们的值直接存在这里
char padding[32]; // 其他属性
} ProtectedObject;
");
// 创建 PHP 对象
$account = new class(100) {
public readonly int $balance; // 物理锁定
public function __construct(int $balance) {
$this->balance = $balance;
}
};
echo "原始余额: {$account->balance}n";
// 尝试 FFI 篡改
// 黑客试图直接操作内存
$ptr = FFI::addr($account); // 获取对象指针的地址（这通常需要 PHP 内部扩展支持，普通 FFI 不直接支持）
// 在 PHP 8.4 的物理加固模式下，试图通过指针修改 readonly 属性
// 如果是通过标准的对象接口访问，这是不可能的。
// 如果是底层的内存操作，PHP 的内存保护机制会介入。
// 我们尝试修改一个假想的偏移量：
try {
$ffi_obj = $ffi->new("ProtectedObject");
// 这里我们无法直接操作 PHP 对象的内存布局，因为 PHP 对象头是私有的。
// 但重点是：如果我们能拿到 $account 的内存地址，并直接写入，
// PHP 8.4 会在底层拦截这个写入操作。
// 假设我们成功写入了：
$ffi_obj->readonly_value = 99999;
echo "篡改成功？余额变成了 {$account->balance}。n";
} catch (Error $e) {
echo "捕获到错误: " . $e->getMessage() . "n";
echo "物理锁定生效！篡改被拒绝。n";
}为什么上面的代码在 PHP 8.4 中会失效或报错？
因为在 PHP 8.4 中，readonly 属性的 Zval 被设置为“写保护”或者直接存储在一个无法通过普通偏移量访问的结构体中。当你试图通过 FFI 修改它时，你实际上是在试图修改 PHP 的内部结构体。PHP 8.4 引入了一种机制，使得这类修改要么失败，要么直接导致 Segfault（因为结构体布局变了）。
这就实现了我们想要的“物理加固”。
第五幕：不仅仅是 FFI——全面防御
我们讨论了 FFI，但 readonly 属性的物理加固不仅仅是为了防 FFI。它彻底改变了我们对 PHP 代码的理解。
1. 克隆与序列化的悖论
在旧版本中，readonly 属性的序列化是有趣的。你把对象存进 Redis，再拿出来，readonly 的属性值还在。这没问题。但是，当你尝试克隆一个 readonly 对象时，旧版本可能会复制那个“只读标记”，结果导致克隆出来的对象在某种程度上也是只读的（虽然这很奇怪）。
在 PHP 8.4 中，物理加固意味着克隆变得更简单也更安全。因为值已经“物理”地嵌入对象中了，复制对象本质上就是复制这些值。不需要去哈希表里拷贝指针了。
2. 作用域内的不可变
这是最让我感到兴奋的一点。PHP 8.4 强制要求 readonly 属性在构造函数中初始化。这意味着，如果你没有在构造函数中给它赋值，你就永远无法给它赋值。
这导致了一个非常酷的现象：构造函数参数变成了类的原生属性。
class Config
{
// 这种写法在 PHP 8.4 中是非常标准的
public function __construct(
public readonly string $apiKey,
public readonly int $timeout,
) {
}
}你看，$apiKey 不再是一个需要手动 __get 的魔法属性，也不需要在外部通过 setter 设置。它在构造函数执行的那一瞬间就被“烙印”在对象上了。这个值是构造函数闭包环境里的一个值。一旦构造函数结束，这个值就被“物理”固化在对象内部。
这就像是 C++ 的 const 成员变量，或者是 Rust 的 struct 字段。PHP 终于在这个特性上追上了 Rust，或者至少是 C++ 的现代风格。
第六幕：深度解析——为什么这叫“物理”加固？
很多开发者会问：“这和以前有什么本质区别？以前也不是不能写死。”
区别在于粒度和语义。
- 以前（逻辑加固）： 属性是一个盒子，盒子上贴了个标签“勿动”。如果你能撕标签，你就能动盒子。
- 现在（物理加固）： 属性不再是一个盒子。它是一块水泥。你要动它，你得把这块水泥从大楼上凿下来，而且还得在不破坏大楼结构的前提下凿下来。这极难，而且系统会报警。
具体到技术实现（基于 RFC 的实现细节）：
PHP 8.4 引入了对象常量的概念，或者更准确地说，它重新定义了对象属性 Zval 的行为。当一个属性是 readonly 时，它的 Zval 不再指向一个动态存储的变量，而是指向一个结构化常量。
这种结构化常量在内存中是只读区域。试图通过 FFI 或指针算术来修改这个区域的内存，在现代操作系统的内存保护机制（如 Linux 的 PROT_READ 页）下，会导致程序崩溃。PHP 8.4 确保了这些 readonly 属性内存页面被标记为不可写。
所以，所谓的“物理加固”，本质上就是：利用内存保护机制，将逻辑上的“只读”变成了物理上的“不可写内存”。
第七幕：给开发者的实战建议
现在，作为一个资深专家，我该如何指导我的团队在 PHP 8.4 中使用这个新特性呢？
-
拥抱 PPH + Readonly：
这是绝配。永远使用构造函数参数属性提升来定义readonly属性。这是最安全、最高效的方式。// 好的写法 public function __construct( public readonly string $id, public readonly array $meta, ) {} -
信任你的构造函数：
既然readonly属性只能在构造函数中初始化，那么确保你的构造函数是绝对的真理来源。不要试图在构造函数结束后再给它赋值。如果你发现需要这样做，说明你的设计可能有问题。 -
防御 FFI 攻击：
如果你的 PHP 应用程序需要调用 C 扩展（例如处理视频编解码、高性能计算），请放心地使用readonly属性来存储敏感数据。这在一定程度上能防止那些试图通过zend_object偏移量直接读取或修改数据的“低级”黑客。 -
避免过度使用：
虽然很酷，但并不是所有东西都需要物理加固。对于频繁变化的临时数据，不要滥用readonly。保持代码的可读性。
第八幕：结局与展望
PHP 8.4 的这次更新，不仅仅是语言特性的迭代，它是 PHP 向“类型安全”和“内存安全”迈出的重要一步。
以前，我们依赖 final 类来防止继承破坏，依赖 readonly 来防止意外修改。但 final 只是告诉别人“别继承我”，而 readonly 在 8.4 之前只是告诉编译器“别让我改”。
现在，PHP 8.4 把 readonly 变成了混凝土。它变成了基础设施的一部分。这不仅保护了数据，也保护了代码的契约。
在这个充满漏洞和黑客的世界里，代码是脆弱的。但有了 PHP 8.4 的物理加固，我们的“黄金宝箱”终于有了真正的墙壁。
希望今天的讲座能让大家明白，当你在构造函数里写下 public readonly 时，你不仅仅是写了一行代码，你是在给你的对象铸造一道防弹装甲。
感谢大家的聆听！现在的代码，比以前更硬了！
（提示：如果你还在用 PHP 8.3 或更早，请尽快升级，否则你的“宝箱”可能随时会被撬开。还有，别试图用 FFI 去读我的演讲稿，字是物理锁定的！）