PHP 8.3未改变构造函数属性提升的默认可见性，仍为public；隐患在于误用public导致敏感字段可直读直写、缺少readonly引发状态失控、拼写错误因动态属性禁用不严而静默创建野字段。
PHP 8.3 并没有改变构造函数参数属性的默认可见性——它依然默认是 public，但这个“默认 public”本身不是新特性，而是自 PHP 8.0 引入“构造函数属性提升”（Constructor Property Promotion）以来就存在的语法糖。真正带来安全隐患的，是开发者误以为“写在构造函数里就等于封装好了”，从而忽略了访问控制、数据校验和只读约束，导致本该受保护的关键字段被随意读写。
下面直击三个最常被忽略、也最易被利用的安全隐患点：
构造函数提升的属性默认 public = 外部可直接读写
当这样写时：
class User {
public function __construct(
public string $id,
public string $email,
public array $roles
) {}
}$id、$email、$roles 全部是 public 属性，意味着：
立即学习“PHP免费学习笔记（深入）”；
- 可被任意代码
$user->email = 'hacker@example.com';直接篡改 - 可被
var_dump()、print_r()或日志函数完整暴露敏感字段（如 token、密钥） - 若用于 DTO 或 API 响应，可能意外泄漏内部结构或未脱敏数据
✅ 正确做法：
PHP 8.5.12 RC 1
下载
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 非必要不暴露；用
private或protected+ 显式 getter 控制读取 - 敏感字段（如
$passwordHash、$apiKey）绝不用public提升
默认 public + 缺少 readonly 约束 = 运行时状态失控
很多配置类、值对象本应“创建即确定”，但开发者只写：
class Config {
public function __construct(
public string $host,
public int $port,
public bool $debug
) {}
}问题在于：
-
$config->debug = true;可在任意位置被翻转，破坏环境一致性 - 若该对象被缓存、共享或跨请求复用，状态污染风险极高
- 攻击者若能通过反序列化或反射注入，可绕过初始化逻辑直接覆写
✅ 正确做法：
- 对不可变字段，强制使用
readonly：public function __construct( public readonly string $host, public readonly int $port, public readonly bool $debug ) {} - PHP 8.3 会确保：一旦构造完成，任何赋值尝试都抛出
Error，连反射也无法绕过（除非用ReflectionProperty::setAccessible(true)+ 特殊权限，但已属高危操作且需明确开启）
public 提升 + 动态属性警告缺失 = 拼写错误静默变成新字段
PHP 8.3 默认禁止动态属性，但如果你写了：
class Order {
public function __construct(public string $id, public float $amount) {}
}
$order = new Order('ORD-001', 99.99);
$order->amout = 88.88; // ❌ 拼错 amount → amout这行代码在 PHP 8.3 中会触发 Deprecated: Creation of dynamic property Order::$amout is deprecated。
但问题在于：如果类用了 #[\AllowDynamicProperties]，或者你忘了加这个注解却仍想“兼容旧逻辑”，那拼写错误就会静默成功，生成一个不受类型约束、无文档、无校验的野字段。
✅ 正确做法：
- 绝不为业务核心类启用
#[\AllowDynamicProperties] - 所有字段必须显式声明，哪怕只是
private string $xxx; - 利用 IDE 和静态分析工具（如 PHPStan）捕获未声明属性访问
不复杂，但容易忽略。关键不是“能不能写”，而是“该不该让别人读/写/碰”。
