PHP 属性钩子处理延迟计算字段的设计

PHP 8.4 的属性钩子解决了一个很具体的问题：字段的读取或写入规则如果只写在 getter、setter 方法里，调用方看到的是一组方法，属性本身的类型和行为却分散了。现在可以把 get 与 set 直接声明在对象属性上，用 get-only 属性表达读取时计算的字段，用 set 钩子集中处理输入规范化。

官方参考：https://www.php.net/language.oop5.property-hooks.php

本文以“用户全名”和“邮箱地址”为例，重点回答三个问题：计算字段怎样做到按需读取、set 钩子里的赋值为什么不会无限递归，以及什么时候应该加缓存而不是每次重新计算。

PHP 8.4 的变化：属性声明可以承载读写逻辑

属性钩子在 PHP 8.4 引入。普通属性以分号结束，带钩子的属性则以花括号结束，里面可以放 get、set 或两者。get-only 属性特别适合表达由其他字段组合出来的值：对象创建时不必先计算，真正读取它时才执行表达式。

这种“延迟”是读取时计算，不等于自动记忆结果。如果底层字段没有改变但读取非常频繁，仍然需要额外的缓存字段和失效策略。先把这两个概念分开，后续的设计才不会误判性能。

先用 get-only 属性表达一个延迟计算字段

下面的 fullName 没有自己的存储值，它只在读取时组合 firstName 和 lastName。这类属性通常称为虚拟属性：它对调用方表现得像字段，但不一定在对象里保存 backing value。

 trim($this->firstName . ' ' . $this->lastName);
    }
}

$customer = new Customer('Lin', 'Wei');
echo $customer->fullName; // 读取时得到 Lin Wei
?>

这里的关键不是把 getter 换成了更短的写法，而是把“这个值只负责读取、来源是哪些字段”放回了属性声明。调用方不需要知道它是拼接结果，也不能直接给 get-only 属性写入一个与来源字段脱节的值。

set 钩子适合做输入规范化和边界校验

对邮箱这类字段，写入规则比读取规则更重要。可以在 set 钩子中统一去除空格、转成小写并校验格式。钩子内部把值写回同名属性时，访问的是 backing value，不会再次从外部触发同一个 set 钩子。

 $this->email;
        set(string $value) {
            // 先统一大小写和首尾空白，避免同一邮箱出现多种存储形式。
            $value = strtolower(trim($value));

            // 无效值直接拒绝，避免把错误数据推迟到更远的业务层。
            if (filter_var($value, FILTER_VALIDATE_EMAIL) === false) {
                throw new InvalidArgumentException('邮箱格式不正确');
            }

            // 钩子内写入 backing value，不会递归调用本钩子。
            $this->email = $value;
        }
    }
}

$account = new Account();
$account->normalizedEmail = '  USER@EXAMPLE.COM ';
echo $account->normalizedEmail; // user@example.com
?>

示例将对外属性名与内部字段名分开，是为了让规则更容易读。实际项目也可以直接给同名属性增加 set，但必须记住钩子内部的同名访问具有 backing value 语义，不能把它当作一次新的外部写入。

三个容易踩到的设计边界

1. 不要把每次 get 都误认为缓存

get => ... 只描述读取时要做什么。若计算包含排序、复杂格式化或远程数据聚合，反复读取可能重复付出成本。可以保存一个私有缓存，并在依赖字段改变时清空它；如果无法定义可靠的失效时机，就保持纯计算，让结果始终跟随源字段。

2. 在 set 中使用 backing value，而不是绕回外部访问

set 钩子应先规范化局部的 $value，校验通过后再写入同名属性的 backing value。不要在钩子里调用会再次写入同一属性的业务方法，否则虽然属性机制本身支持 backing value，业务层仍可能人为制造递归。

3. 迁移前确认版本和 readonly 约束

属性钩子是 PHP 8.4 能力，PHP 8.3 及更早版本不能解析这套语法。官方手册还明确说明属性钩子与 readonly 属性不兼容；如果既要改变读写行为又要限制外部写入，应评估非对称可见性等 PHP 8.4 能力，而不是把两个声明硬拼在一起。

用最小检查确认语法和钩子存在

发布前至少要在 PHP 8.4 环境执行语法检查和一条读取/写入断言。若项目使用反射或框架元编程，还可以检查属性是否真的声明了钩子。下面的检查不会依赖浏览器或额外扩展。

fullName !== 'Lin Wei') {
    throw new RuntimeException('fullName 计算结果不符合预期');
}

// 反射可帮助框架确认属性上是否存在 get 钩子。
$property = new ReflectionProperty(Customer::class, 'fullName');
if (!$property->hasHook(PropertyHookType::Get)) {
    throw new RuntimeException('fullName 缺少 get 钩子');
}

echo "property hooks ok\n";
?>

这里的检查重点是边界，不是为了把一个简单类包装成测试框架：PHP 版本要足够新，get-only 属性必须可读不可写，set 钩子要能拒绝无效输入，反射检查则只在确实需要框架识别时加入。

什么时候值得从 getter/setter 迁移

如果旧代码的 getter 只是返回计算结果，迁移到 get-only 属性通常能让对象接口更贴近业务字段；如果 setter 负责规范化和校验，迁移后可把写入契约放在属性附近。但不要为了追求新语法而一次性改动稳定公共 API：外部调用方已经依赖 getFullName() 或接口方法时，可以先保留旧方法，让它内部转发到新属性，再分阶段调整调用方。

最终可以用下面的速查表做决定：

相关问题

属性钩子只能用于静态属性吗？

不能。属性钩子针对对象属性；静态属性不适用这套 get/set 行为。

get-only 属性能不能直接赋值？

不能把它当作普通可写字段。它适合由其他状态推导结果；需要持久化值时，应使用有 backing value 的属性并明确写入入口。

set 钩子里给同名属性赋值会递归吗？

钩子内部对同名属性的直接访问指向未过滤的 backing value，不会因为这一句自动再次触发 set。不过，仍要避免在钩子里调用会从外部再次写入该属性的业务流程。

属性钩子适合替代所有 getter 和 setter 吗？

不适合。跨字段副作用、远程调用、复杂事务或需要保持旧接口的方法，仍可保留显式方法。属性钩子更适合局部、可读且能贴近字段声明解释清楚的读写规则。

PHP 属性钩子的价值不只是减少几行 getter/setter，而是把“读取时计算”和“写入时约束”明确放在属性契约旁边。先用 get-only 属性处理无副作用的延迟计算，再用 set 钩子收敛输入规则，最后根据实际计算成本决定是否增加缓存，这样迁移更容易控制。