本文探讨 php 中构建器模式与不可变性的本质矛盾，指出纯不可变构建器在实践中不可行，并提供兼顾可读性、灵活性与合理不变性的实用方案——通过返回新实例而非修改自身来实现逻辑不可变。
在面向对象设计中，“构建器模式”（Builder Pattern）常用于简化复杂对象的创建过程，尤其适用于参数众多、部分可选的场景；而“不可变性”（Immutability）则强调对象一旦构造完成，其状态便不可更改。乍看之下，二者目标冲突：构建器需逐步设置属性，而不可变对象禁止任何状态变更。
但关键在于——不可变性应作用于最终产物，而非构建过程本身。真正的不可变构建器并非要求 Builder 实例自身不可变（这会使其无法链式调用），而是确保每次调用如 withName() 或 withId() 都返回一个全新的、状态确定的新构建器实例，原实例保持不变。这才是符合语义的“逻辑不可变”（value-level immutability）。
Modoer多功能点评系统2.5 精华版 Build 20110710 UTF8
下载
Modoer 是一款以本地分享，多功能的点评网站管理系统。采用 PHP+MYSQL 开发设计，开放全部源代码。因具有非凡的访问速度和卓越的负载能力而深受国内外朋友的喜爱，不局限于商铺类点评，真正实现了多类型的点评，可以让您的网站点评任何事与物，同时增加产品模块，也更好的网站产品在网站上展示。Modoer点评系统 2.5 Build 20110710更新列表1.同步 旗舰版系统框架2.增加 限制图片
✅ 正确实现：值语义 + 不可变副本
自 PHP 8.2 起，readonly 属性配合构造器参数提升（constructor property promotion）和只读数组支持，使该模式变得简洁可靠：
id, $this->email, $this->roles);
}
public function withId(int $id): self
{
return new self($this->name, $id, $this->email, $this->roles);
}
public function withEmail(?string $email): self
{
return new self($this->name, $this->id, $email, $this->roles);
}
public function withRole(string $role): self
{
$roles = [...$this->roles, $role];
return new self($this->name, $this->id, $this->email, $roles);
}
public function build(): array
{
return [
'name' => $this->name,
'id' => $this->id,
'email' => $this->email,
'roles' => $this->roles,
];
}
}
// 使用示例：全程无副作用，每次调用都产生新实例
$user = (new UserBuilder())
->withName('Alice')
->withId(42)
->withEmail('alice@example.com')
->withRole('user')
->withRole('admin')
->build();
print_r($user);
// 输出：
// Array (
// [name] => Alice
// [id] => 42
// [email] => alice@example.com
// [roles] => Array ([0] => user, [1] => admin)
// )⚠️ 注意事项与权衡
- 性能考量：频繁克隆对象会产生额外内存开销。对高性能敏感场景（如高频循环构建），可权衡是否采用“半不可变”策略（如仅保证 build() 后不可变，构建中允许内部可变，但对外不暴露修改接口）。
- 深拷贝陷阱：若属性含嵌套对象或资源（如 DateTime、Closure），需手动处理深拷贝逻辑，否则仍可能意外共享状态。
- 类型安全增强：结合 PHP 8.3+ 的 enum 和 readonly 类，或使用静态分析工具（如 PHPStan）校验构建路径，可进一步强化契约保障。
- 不必强求绝对不可变：正如答案所强调——理论是为理解服务，而非枷锁。若构建器仅作为临时工具、生命周期极短且不被共享，适度的内部可变性（如你第一个示例）完全可接受，且更直观高效。
✅ 总结
- 真正的“不可变构建器”，核心是方法调用不改变当前实例，而是返回新实例；
- 利用 readonly 属性 + 构造器参数 + 显式 new self(...) 是 PHP 当前最清晰、最安全的实现方式；
- 不必因追求理论完美而牺牲可维护性；明确构建器的职责边界（它只是通往不可变值的桥梁），比纠结其自身是否“100% 不可变”更有实践价值。
