解读

国内一线/二线公司在社招/校招面试中，常把 Constructor Property Promotion（构造器属性提升）作为“PHP8 新特性”必考点。
面试官真正想验证的是：

1. 你是否真的用 PHP8 写过业务代码，而不是“背版本号”；
2. 对语法糖背后的抽象、性能、可维护性有没有工程级思考；
3. 能否在代码评审场景下，指出旧写法的问题并给出重构方案。
   因此，回答要“落地”：先给出语法差异，再算“三笔账”（代码量、性能、心智负担），最后结合 PSR 规范、单元测试、静态分析工具说明最佳实践。

知识点

1. 语法本质：在构造方法形参前加访问修饰符（public / protected / private），编译阶段自动转为类属性并赋值，不再需要在方法体内 $this->x = $x。
2. 与旧写法的差异：旧写法需声明属性 + 构造赋值两步，Promotion 一步完成；同时支持默认值、只读（readonly）修饰符、联合类型、属性注解（Attribute）。
3. OPcache 层面：Promotion 生成的 opcodes 与旧写法几乎等价，无额外性能损耗；但少一次“人工赋值”操作，理论上降低一条 ASSIGN 指令，可忽略不计。
4. 可读性与评审：减少 30%～50% 样板代码，降低新人犯错概率（如漏写 $this->x = $x 或写错变量名）。
5. 与 PSR-12 兼容性：PSR-12 强制构造方法参数每行一个，Promotion 写法天然符合。
6. 与 readonly 结合：PHP 8.1 起可写 public readonly string $name，实现真正不可变对象，Promotion 语法同样支持。
7. 与静态分析、IDE 的协同：PhpStorm、Psalm、PHPStan 均原生识别 Promotion 属性，类型推断精准，减少 False Positive。
8. 局限：
   • 只能在构造方法内使用；
   • 若属性需要复杂校验（throw Exception），仍需在方法体内手动赋值；
   • 与“工厂方法”“反射构造”混用时，需评估可读性。

答案

“Constructor Property Promotion 是 PHP8 引入的零成本语法糖，它把‘声明属性 + 构造赋值’两步合并为一步，直接在构造方法参数前加访问修饰符即可。
优势可以总结为‘三省’：

1. 省代码：一个中等 DTO 类可从 40 行压缩到 15 行，减少 60% 样板代码，代码评审时 diff 更聚焦业务；
2. 省错误：消灭人工 $this->x = $x 的笔误、漏写、类型不匹配的隐患，结合静态分析工具可直接在 CI 阶段报错；
3. 省心智：符合 PSR-12 的换行规范，新人一眼看出哪些参数会提升为属性，降低上手成本。
   在性能层面，OPcache 生成的 opcode 与旧写法等价，无额外开销；在可维护性层面，与 readonly、联合类型、属性注解无缝结合，可轻松实现‘不可变值对象’，非常适合领域模型、DTO、VO 场景。
   落地到团队规范，我们规定：所有纯数据对象必须采用 Promotion，并在合并请求里用 PHPStan level8 扫描，若出现复杂初始化逻辑再退回到方法体内手动赋值，这样兼顾简洁与安全。”

拓展思考

1. 如果属性需要在构造时做跨字段校验（例如 startDate < endDate），Promotion 是否仍然适用？你会如何设计？
2. 当类需要支持“序列化/反序列化”或“JSON 转对象”时，Promotion 属性与反射、构造器注入如何协作？是否需要自定义 __unserialize()？
3. 在微服务接口升级场景，DTO 新增字段不可避免。使用 Promotion 后，如何借助“默认参数”实现向后兼容，同时保证旧版本客户端不传新字段时不会 500？
4. 与 Java 的“记录类”（Record）相比，PHP 的 Promotion + readonly 还缺哪些语言级能力？未来若 PHP 引入原生 Record，现有 Promotion 代码迁移成本如何评估？