PHP 8.4 属性钩子读取和写入校验如何分工

PHP 8.4 属性钩子的分工可以先记成一句话：get 决定“读出来是什么”，set 决定“写进去之前如何检查和转换”。读取格式化不应该偷偷修改输入，写入校验也不应该承担展示层拼接。属性钩子官方手册地址是 https://www.php.net/manual/en/language.oop5.property-hooks.php。

get 负责读取结果，set 负责接收和校验输入

一个属性同时声明两个钩子时，外部读取会进入 get，赋值会进入 set。最容易维护的写法是让 set 处理输入的清洗和约束，让 get 只负责返回已经可靠的数据或计算展示值。这样调用方仍然使用普通的 $profile->displayName，却不需要知道内部校验细节。

storedName;
        }
        set(string $value) {
            // 写入先清洗输入，再拒绝空字符串，最后保存可靠值。
            $value = trim($value);
            if ($value === '') {
                throw new InvalidArgumentException('姓名不能为空');
            }
            $this->storedName = $value;
        }
    }
}

$profile = new Profile();
$profile->displayName = '  林默  '; // set 保存为“林默”。
echo $profile->displayName;       // get 返回“林默”。
?>

这里的 displayName 没有在钩子中访问 $this->displayName，所以它是 virtual property；真正的存储位置是 $storedName。读写职责被拆开后，后续增加大小写、长度或格式限制时，不会污染读取逻辑。

用 virtual property 或 backing value 选择存储方式

属性钩子不等于自动产生一份新的数据。若钩子通过 $this->属性名 访问同名属性，PHP 会把它当作 backing value；在钩子内部的这次直接访问用于读写未过滤的底层值，不会再次绕回同一钩子。若钩子完全不碰同名属性，它就是 virtual property，适合“由其他字段计算出来”的值。

例如全名可以由姓和名即时拼接，这种属性不需要重复存储；而规范化后的用户名通常应该保留 backing value。不要在 get 中调用公开赋值路径来“顺便修正”数据，否则会让读取产生隐式写入。

用反射和边界输入验证钩子分工

验证时不要只看一次正常输出。先用反射确认声明，再分别覆盖空字符串、带空格输入和合法输入。getHooks() 返回以 get、set 为键的反射方法；没有对应钩子时，该键不存在。

getHooks();

// 反射确认两个方向都已声明，避免测试只覆盖了读取路径。
var_dump(array_keys($hooks)); // 预期包含 get 和 set

$profile = new Profile();
try {
    $profile->displayName = '   '; // 边界输入应被 set 拒绝。
} catch (InvalidArgumentException $e) {
    echo $e->getMessage(); // 只记录可理解的校验结果。
}

$profile->displayName = '  林默  ';
echo $profile->displayName; // 预期只读到清洗后的值。
?>

如果需求是“外部可读、类内部可写”，优先考虑 PHP 8.4 的 public private(set) 或 protected(set)。它解决的是访问权限；get/set 解决的是读写行为，两者可以组合但不要混为一谈。

常见问题：类型、递归和只读需求怎么处理

只声明 set，可以从外部读取吗？

不能把它当成普通可读属性。只提供写入操作的属性适合接收值或触发动作；需要对外展示时，应另外声明可读属性或提供明确的 get 行为。

set 钩子里的参数类型能更宽吗？

可以在符合类型兼容规则的前提下接受更宽的输入，但不要用不相关的类型绕过属性本身的类型约束。业务校验仍应在 set 内明确完成。

属性钩子能替代 readonly 吗？

不能简单替代。属性钩子关注读写行为，readonly 关注初始化后的修改限制；如果还要控制谁能写，使用非对称可见性或普通方法表达意图更清楚。