代理模式仅在真实对象创建开销大且访问频率低时适用；UserDataProxy 通过延迟实例化、接口契约和异常安全机制实现按需加载，避免盲目使用导致性能下降。
代理模式不是万能的延迟开关，它只在真实对象创建开销大、且访问频率低时才值得引入；盲目套用反而增加调用链和内存占用。
为什么直接 new UserData() 会拖慢接口？
当 UserData 构造函数里做了数据库查询、远程 API 调用或解析大 JSON，每次实例化都触发这些操作，哪怕后续根本没用到它的属性。尤其在循环中批量处理用户时，new UserData($id) 可能变成 N 次无意义的 IO。
- 构造即执行：没有“只声明不加载”的中间态
- 无法按需拦截：你不能在
$user->getProfile()被调用前阻止初始化 - 耦合度高：业务逻辑和加载逻辑混在一起，测试和替换成本高
Proxy 类必须实现相同接口才能透明替换
PHP 的代理模式依赖接口契约——UserDataProxy 和 UserData 必须共用一个接口（如 UserDataProvider），否则客户端代码一访问就会报错 Fatal error: Call to undefined method UserDataProxy::getName()。
- 接口定义所有可访问方法，代理类只负责转发或增强，不新增行为
- 构造
UserDataProxy时不实例化UserData，只存$id和工厂回调 - 首次调用任意方法（如
getName()）时，才执行工厂函数生成真实实例并缓存 - 后续调用直接走真实对象，不再经过代理逻辑
示例关键片段：
立即学习“PHP免费学习笔记（深入）”；
class UserDataProxy implements UserDataProvider
{
private $id;
private $realInstance;
public function __construct(int $id)
{
$this->id = $id;
}
private function getRealInstance(): UserDataProvider
{
if (null === $this->realInstance) {
$this->realInstance = new UserData($this->id); // 真正加载发生在这里
}
return $this->realInstance;
}
public function getName(): string
{
return $this->getRealInstance()->getName();
}
}
别把 Proxy 当 ORM 关联懒加载来用
ThinkPHP 的 load('profile') 或 Laravel 的 $user->profile 是框架层对关联关系的语法糖，底层仍是 SQL 查询控制；而 PHP 原生 Proxy 模式控制的是对象实例化时机，两者作用域完全不同。混用会导致双重延迟、缓存失效或状态不一致。
-
UserDataProxy解决的是“要不要 new UserData”，不是“查不查 profile 表” - 如果
UserData本身已用 Eloquent 实现了关联懒加载，再套一层UserDataProxy就是叠床架屋 - 代理类里不应包含数据库操作逻辑，那属于
UserData的职责；代理只管“何时 new”和“是否缓存” - 注意克隆行为：
clone $proxy会触发初始化并克隆真实对象，不是复制代理壳
工厂函数抛异常时，代理状态自动回滚
这是容易被忽略的安全机制：如果 UserData 构造时因网络超时或数据缺失抛出异常，UserDataProxy 不会留下半初始化对象，而是恢复为“未加载”状态，下次调用仍会重试。但要注意——这个回滚只限代理自身属性，不撤销工厂函数里的外部副作用（比如已发的日志、已写的临时文件）。
- 异常后再次调用方法，会重新执行工厂函数，不是直接失败
- 若需幂等，工厂函数内部应自行处理重试或降级（如返回空对象）
- 不要在工厂函数里修改代理对象的属性，初始化完成后它们会被丢弃
