PHP 8.3 通过 readonly 属性、类型化类常量、#[Override] 属性及新函数增强工厂模式可靠性：readonly 保障对象不可变，类型化常量强化契约，#[Override] 防止子类破坏LSP，json_validate() 和 mb_str_pad() 提升配置处理鲁棒性。
PHP 8.3 的新特性本身不直接“优化”工厂模式，但能显著减少样板代码、强化类型约束、降低误用风险——尤其在构造逻辑集中、对象不可变性要求高的场景下。
readonly 属性 + 构造器提升让工厂返回值更可信
传统工厂常返回已初始化对象，但无法阻止调用方后续篡改状态。PHP 8.3 允许在类定义中直接声明 readonly 属性并设默认值，配合构造器提升，工厂方法可返回真正“封印过”的实例。
- 工厂无需再手动赋值或做防御性拷贝，
public function __construct(public readonly string $id, public readonly array $config = [])一行搞定初始化与只读锁定 - 若属性需动态计算（如从配置生成哈希 ID），仍须在构造函数体内赋值，此时
readonly仍生效，但不能设默认值 - 注意：数组默认值仅支持字面量（如
['host' => 'localhost']），不能写get_default_config()—— 否则报ParseError: Readonly property ... cannot have dynamic default value
typed class constants 强化工厂契约表达力
工厂常依赖常量标识产品类型（如 UserFactory::TYPE_ADMIN），过去这些常量无类型约束，易传错或被意外覆盖。PHP 8.3 支持显式类型化类常量，让意图更明确、IDE 更易校验。
- 写法：
final class UserFactory { public const TYPE_ADMIN: string = 'admin'; public const MAX_RETRY: int = 3; } - 好处：调用方使用
UserFactory::TYPE_ADMIN时，静态分析工具能确认其必为string；若误写成UserFactory::TYPE_ADMIN = 123，PHP 解析期即报错 - 限制：常量类型必须是标量、
array、null或其他已声明的类名，不支持联合类型（如string|int）作为常量类型
#[\Override] 属性帮工厂子类守住 LSP 契约
当抽象工厂有多个实现（如 MySQLUserFactory、PostgresUserFactory），子类重写方法时容易漏掉关键逻辑或改错签名。PHP 8.3 的 #[\Override] 属性强制标注覆盖行为，编译器会验证父类是否存在同名方法及签名兼容性。
立即学习“PHP免费学习笔记（深入）”；
- 在子类工厂中写
#[\Override] public function create(): User，若父类没定义create()或返回类型不一致（如父类是User|null，子类是User），PHP 启动时就报TypeError - 这比运行时才发现“子类返回了非预期类型”更早拦截问题，对长期维护的工厂继承体系很实用
- 注意：该属性不检查方法体逻辑，只校验存在性和签名；若父类方法是
final，加#[\Override]会直接报错
json_validate() 和 mb_str_pad() 在工厂配置加载环节更稳
工厂常需解析外部配置（如 JSON 文件）或对标识符做标准化填充。PHP 8.3 内置 json_validate() 和 mb_str_pad()，避免引入第三方库或手写容错逻辑。
-
json_validate($raw)比json_decode($raw, null, 512, JSON_THROW_ON_ERROR)更轻量，不抛异常、不解析结构，纯校验语法有效性，适合配置预检 -
mb_str_pad($id, 8, '0', STR_PAD_LEFT, 'UTF-8')可安全处理中文等多字节字符的填充，避免str_pad()在非 ASCII 场景下截断或乱码 - 这两个函数不改变工厂核心逻辑，但让配置加载、ID 生成等辅助环节更鲁棒，间接提升工厂整体可靠性
真正关键的不是“用了多少新特性”，而是哪些地方必须用——比如只读属性一旦漏掉构造器赋值，运行时才爆 Error: Cannot modify readonly property；而 #[\Override] 若忘记加，子类可能静默破坏契约。这些点容易被忽略，但恰恰决定工厂在复杂系统中是否扛得住迭代压力。
