PHP 8.3 的新功能与改进：完整技术参考

PHP 8.3 是 PHP 语言的一个重要次要版本，对 JIT 编译器、类型系统、readonly 属性以及核心数组/字符串函数进行了重大改进。该版本于 2023 年 11 月 23 日发布，引入了类型化类常量、json_validate()、array_is_list() 改进、Randomizer 新增功能以及 readonly 属性的深度克隆——这些变化直接影响生产服务器上的应用程序性能、代码正确性和可维护性。

如果您在 VPS 托管环境或独立服务器上运行基于 PHP 的工作负载，那么了解 PHP 8.3 的每项变更不是可选项——而是做出明智升级决策、避免隐性回归以及获得可量化性能提升的前提条件。

PHP 8.2 与 PHP 8.3 之间的变化

在深入了解各项功能之前，有必要先明确此版本的范围。PHP 8.3 并非破坏性重写，而是一次精准升级，填补了类型系统中长期存在的空白，强化了 JIT 流水线，并添加了以前需要用户态变通方案的实用函数。下表列出了最具影响力的变化及其对应的 PHP 8.2 等效项。

> 重要更正：原文错误地声称 str_contains() 在 PHP 8.3 中接受字符串数组。这在事实上是错误的。str_contains() 仅接受两个字符串参数。传入数组会触发 TypeError。在多个字符串中搜索子字符串的正确方法是将 array_filter() 与 str_contains() 结合使用，或使用 in_array() 进行精确匹配。

PHP 8.3 中的 JIT 编译：实际变化

背景：PHP JIT 的工作原理

PHP 的 JIT 编译器在 PHP 8.0 中作为实验性功能引入，作为 OPcache 子系统的扩展运行。它在运行时将热字节码路径编译为本机机器码，绕过这些路径的 Zend VM 解释器。PHP 8.3 附带了经过大幅修订的 JIT 后端，改进了编译期间使用的中间表示（IR）。

PHP 8.3 中基于 IR 的新 JIT（由 Dmitry Stogov 开发）用适当的 SSA 形式中间表示替换了旧版追踪 JIT 的代码生成层。这实现了更好的寄存器分配、死代码消除和循环不变量提升——这些优化在以前的架构中从结构上是不可能实现的。

正确启用 JIT

原文显示 php -d jit=on script.php，这是不完整的。JIT 需要 OPcache 处于活动状态。CLI 基准测试或生产 php.ini 的正确最小配置为：

; php.ini
opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

对于 Web 服务器上下文（FPM 或 Apache mod_php），opcache.enable_cli 无关紧要，但 opcache.jit_buffer_size 必须为非零值，否则 JIT 会静默禁用自身。一个常见的生产陷阱是在共享的 php.ini 中设置 jit_buffer_size=0，然后疑惑为何 JIT 没有效果。

JIT 何时能带来可量化的收益

JIT 并非普遍有益。其收益集中在 CPU 密集型工作负载中：

• 高价值目标：数学计算、图像处理、机器学习推理、游戏逻辑、CSV/数据解析循环、用户态加密操作。
• 低价值目标：典型的 CRUD Web 应用程序，其瓶颈在于 I/O（数据库查询、文件系统、网络）。在这些情况下，JIT 编译开销可能会略微增加内存使用量，而吞吐量改善可以忽略不计。
• 负面情况：代码路径极为多样化的应用程序（具有大量反射的大型框架）可能会导致 JIT 缓冲区抖动，造成反优化开销。

实用规则：首先使用 opcache.jit=tracing 进行基准测试。如果您在实际工作负载上看到的改善不足 3%，请禁用 JIT 以将缓冲区内存恢复给 OPcache 的操作码缓存，这对所有 PHP 应用程序都有统一的好处。

类型化类常量

对于大型代码库而言，这可以说是 PHP 8.3 中最具影响力的类型系统新增功能。

它解决的问题

在 PHP 8.3 之前，类常量没有强制类型。子类可以用完全不兼容的类型重新定义常量，PHP 不会在运行时报错——或者根本不报错，这取决于常量的使用方式。

// PHP 8.2 — no type enforcement
interface StatusCode {
    const SUCCESS = 200; // implicitly int
}

class BrokenStatus implements StatusCode {
    const SUCCESS = "two hundred"; // silently accepted — a maintenance nightmare
}

PHP 8.3 解决方案

// PHP 8.3 — type is enforced at definition and inheritance
interface StatusCode {
    const int SUCCESS = 200;
}

class BrokenStatus implements StatusCode {
    const int SUCCESS = "two hundred";
    // Fatal error: Cannot use string as value for typed class constant
    // BrokenStatus::SUCCESS of type int
}

所有标量类型（int、float、string、bool）、array、null、联合类型和交叉类型均可用于常量类型声明。never 和 void 类型不被允许。此功能与 PHPStan 和 Psalm 等静态分析工具完美集成，无需运行时开销即可实现更严格的接口契约。

动态类常量和枚举成员获取

PHP 8.3 允许使用 ::{} 语法中的运行时表达式获取类常量和枚举成员。

class Direction {
    const string NORTH = 'north';
    const string SOUTH = 'south';
}

$direction = 'NORTH';
echo Direction::{$direction}; // outputs: north

以前，这需要 constant() 或 match 表达式，两者都冗长且容易出错。新语法也适用于枚举：

enum Color {
    case Red;
    case Blue;
}

$name = 'Red';
$color = Color::{$name}; // Color::Red

需注意的边缘情况：如果变量包含的名称与已定义的常量或枚举用例不对应，PHP 会抛出 Error 异常——而非警告。在使用前，请将动态获取包装在 try/catch 块中，或使用 defined() / enum_exists() 进行验证。

json_validate() 函数

为何在生产环境中重要

在 PHP 8.3 之前，在不解码 JSON 字符串的情况下验证它的惯用方式是：

json_decode($input);
$isValid = json_last_error() === JSON_ERROR_NONE;

这种方法将 JSON 完全解码为 PHP 结构，分配与有效载荷大小成比例的内存。对于仅验证的流水线——API 网关、消息队列消费者、Webhook 接收器——这是一种浪费。

PHP 8.3 原生验证

$payload = '{"user": "alex", "role": "admin"}';

if (json_validate($payload)) {
    // safe to decode
    $data = json_decode($payload, true);
}

// Invalid JSON
var_dump(json_validate('{invalid}')); // bool(false)

json_validate() 在不构建 PHP 值树的情况下解析 JSON 结构。内存消耗为 O(深度) 而非 O(大小)，使其对大型有效载荷显著更高效。它还接受与 json_decode() 一致的 $depth 和 $flags 参数。

实际使用场景：每分钟处理 50,000 个请求的 Webhook 接收器可以使用 json_validate() 在任何反序列化发生之前在边缘拒绝格式错误的有效载荷，从而大幅降低 CPU 和内存压力。

Readonly 属性：深度克隆支持

PHP 8.2 引入了 readonly 属性，但使其在对象克隆期间也无法修改。这迫使开发人员采用笨拙的变通方案——工厂方法、序列化技巧，或完全放弃值对象的 readonly。

PHP 8.3 通过允许 __clone() 魔术方法在克隆上下文中重新分配 readonly 属性来解决这个问题。

class ImmutablePoint {
    public function __construct(
        public readonly float $x,
        public readonly float $y,
    ) {}

    public function withX(float $x): static {
        $clone = clone $this;
        $clone->x = $x; // Legal in PHP 8.3 within __clone context
        return $clone;
    }
}

$point = new ImmutablePoint(1.0, 2.0);
$moved = $point->withX(5.0);

echo $moved->x; // 5.0
echo $point->x; // 1.0 — original unchanged

此模式是领域驱动设计中不可变值对象的基础。没有它，readonly 对于复杂领域模型来说在很大程度上只是装饰性的。

#[Override] 属性

#[Override] 属性向 PHP（和静态分析工具）发出信号，表明某个方法旨在覆盖父类或接口方法。如果父方法不存在，PHP 会抛出编译时错误。

class Base {
    public function process(): void {}
}

class Child extends Base {
    #[Override]
    public function process(): void {
        // If Base::process() is renamed or removed, this becomes a fatal error
    }
}

这在大型团队中特别有价值，因为重构基类可能会静默破坏子类覆盖。该属性充当编译时契约，捕获以前只在运行时或通过静态分析才能发现的一类错误。

array_is_list() 与正确的数组分类

array_is_list() 是在 PHP 8.1 中引入的，而非 8.3。然而，其正确使用模式值得精确记录，因为该函数经常被误解。

当且仅当以下情况时，PHP 数组才是列表：

1. 它是空的，或者
2. 其键是从 0 开始的连续整数，没有间隔。

var_dump(array_is_list([]));                          // bool(true)
var_dump(array_is_list([0 => 'a', 1 => 'b']));        // bool(true)
var_dump(array_is_list(['a', 'b', 'c']));              // bool(true)
var_dump(array_is_list([1 => 'a', 0 => 'b']));         // bool(false) — wrong order
var_dump(array_is_list([0 => 'a', 2 => 'b']));         // bool(false) — gap at index 1
var_dump(array_is_list(['key' => 'value']));            // bool(false) — string key

实际应用：将数据序列化为 JSON 时，array_is_list() 决定输出应该是 JSON 数组（[]）还是 JSON 对象（{}）。在 json_encode() 之前使用它可以防止已删除元素的数字索引数组意外序列化为对象。

PHP 8.3 中的新随机化方法

PHP 8.2 中引入的 RandomRandomizer 类新增了三个重要方法：

getBytesFromString()

$randomizer = new RandomRandomizer();
$token = $randomizer->getBytesFromString('abcdefghijklmnopqrstuvwxyz0123456789', 16);
echo $token; // e.g., "k3mz9xqp1wvn7yt2"

这会从指定字母表中生成加密安全的随机字符串——这是令牌生成、OTP 代码和 slug 创建所需的模式。以前，这需要使用 random_int() 手动循环。

getFloat() 和 nextFloat()

$randomizer = new RandomRandomizer();

// Returns a float in [0.0, 1.0)
$value = $randomizer->nextFloat();

// Returns a float in a specified closed or half-open interval
$scaled = $randomizer->getFloat(1.5, 9.5, RandomIntervalBoundary::ClosedOpen);

getFloat() 使用 γ-section 算法生成均匀分布的浮点数，避免了影响朴素实现的模偏差。这对于分布均匀性至关重要的模拟、概率算法和 A/B 测试框架来说非常关键。

PHP 8.3 中的弃用和移除

了解正在逐步淘汰的内容与了解正在添加的内容同样重要。现在忽略弃用意味着在 PHP 9.0 中出现致命错误。

性能基准：PHP 8.3 与以前版本的对比

根据 Kinsta、Phoronix 和 PHP 内部团队使用 Symfony Demo、WordPress 以及原始 Fibonacci/排序工作负载发布的基准测试：

对于 I/O 密集型应用程序，收益是一致的，但并不显著。PHP 8.3 中的 JIT 改进在纯计算工作负载中显示出最显著的差异——在 Mandelbrot 基准测试中比 PHP 8.2 快高达 18%。

升级到 PHP 8.3：实用服务器端检查清单

如果您管理自己的服务器基础设施——无论是在带 cPanel 的 VPS 上还是裸机独立服务器上——在升级生产环境之前请遵循以下步骤。

升级前步骤

• 运行 composer outdated 并将所有依赖项更新到已声明 PHP 8.3 兼容性的版本。
• 在 PHP 8.3 CLI 下执行 php -d error_reporting=E_ALL your_app_entrypoint.php，在弃用通知变成致命错误之前将其暴露出来。
• 审计任何使用非字符串参数调用 str_contains()、str_starts_with() 或 str_ends_with() 的代码——在严格上下文中这些现在会抛出 TypeError。
• 检查子类覆盖的任何类常量——如果类型不兼容，类型化常量将导致致命错误。
• 升级后检查 phpinfo() 输出，确认 OPcache 和 JIT 以预期配置处于活动状态。

PHP 8.3 生产环境的 php.ini 调优

; Recommended production baseline for PHP 8.3
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.jit=tracing
opcache.jit_buffer_size=64M

设置 validate_timestamps=0 可禁用每次请求的文件修改检查——这对于 OPcache 失效开销可量化的高流量部署至关重要。改为在代码部署后使用部署钩子调用 opcache_reset()。

升级后验证

# Verify active PHP version
php -v

# Confirm JIT is compiled in and active
php -r "var_dump(opcache_get_status()['jit']);"

# Check for deprecation notices in error log
tail -f /var/log/php-fpm/error.log | grep -i deprecat

PHP 8.3 与 Web 应用程序安全注意事项

PHP 8.3 没有引入新的安全原语，但有几项变化具有间接的安全影响：

• json_validate() 减少了攻击面，通过防止格式错误的 JSON 到达反序列化逻辑来保护输入验证流水线。
• 类型化类常量防止类型混淆攻击，其中子类为安全相关常量（例如权限级别或超时值）替换意外类型。
• #[Override] 属性防止安全关键基类中的静默方法遮蔽，这是插件架构中微妙权限提升错误的一个向量。
• RandomRandomizer 新增功能替换了用于令牌生成的不安全模式，如 substr(str_shuffle(implode(range('a','z'))), 0, 16)。

对于处理敏感数据的应用程序，将 PHP 8.3 与正确配置的 TLS 栈配对是不可或缺的。如果您的托管环境尚未部署最新的 SSL 证书，请在进行任何 PHP 升级之前先解决这个问题。

为 PHP 8.3 选择合适的托管环境

PHP 8.3 的 JIT 编译器和类型化常量解析增加的内存需求意味着资源受限的环境可能无法从升级中充分受益。

• 共享托管：PHP 版本可用性完全取决于提供商。如果您需要立即使用 PHP 8.3，支持 PHP 版本切换的共享虚拟主机方案可在无需服务器管理开销的情况下提供灵活性。
• VPS：完全控制 php.ini、PHP-FPM 池配置、OPcache 调优和 JIT 缓冲区大小。这是启用 JIT 的生产 PHP 8.3 部署的最低推荐环境。
• 独立服务器：适用于高流量应用程序，其中多个 PHP-FPM 工作进程之间的 JIT 缓冲区争用成为瓶颈。专用环境还允许为 OPcache 进行 NUMA 感知内存分配。
• GPU 托管：如果您的 PHP 应用程序协调 GPU 加速工作负载（例如调用 Python ML 推理服务），则相关。GPU 托管环境受益于 PHP 8.3 改进的 FFI 和进程管理。

关键技术要点和决策矩阵

在以下情况下立即使用类型化类常量：

• 您的代码库使用带有子类覆盖的常量的接口或抽象类。
• 您使用 PHPStan 级别 8 或 Psalm——类型化常量可实现更严格的分析。

在以下情况下启用 JIT：

• 您的分析器显示 CPU 时间超过请求时间的 40%。
• 您在 PHP 中运行批处理、数据转换或数学工作负载。
• 每个 PHP-FPM 池至少有 64 MB 的专用 OPcache JIT 缓冲区可用。

在以下情况下不要启用 JIT：

• 您的应用程序是 I/O 密集型的（数据库、缓存、文件系统、API 调用主导延迟）。
• 您在 OPcache 内存有限的共享托管上。
• 您尚未对特定工作负载进行基准测试——不要假设任何事情。

在以下情况下采用 json_validate()：

• 您在代码库中的任何地方在解码之前验证 JSON。
• 您处理大量 Webhook 或消息队列有效载荷。

将 #[Override] 添加到：

• 子类中每个有意覆盖父方法的方法。
• 插件或扩展架构中安全关键的方法覆盖。

在以下情况下迁移到 RandomRandomizer：

• 您的代码的任何部分使用 rand()、mt_rand()、array_rand() 或 str_shuffle() 进行安全敏感的令牌或密钥生成。

常见问题

PHP 8.3 是否会破坏与 PHP 8.2 代码的向后兼容性？

在大多数情况下，不会。PHP 8.3 是一个次要版本，没有从标准库中删除在 8.2 中尚未弃用的函数。但是，新弃用的行为将发出 E_DEPRECATED 通知，任何依赖常量中隐式类型强制或带浮点步长的 range() 的代码可能会有不同的行为。在部署之前，始终在 PHP 8.3 下运行您的测试套件。

PHP 8.3 中 JIT 是否默认启用？

不是。JIT 需要启用 OPcache 并将 opcache.jit_buffer_size 设置为非零值。大多数发行版附带的默认 php.ini 将 opcache.jit_buffer_size=0 设置为有效禁用 JIT。您必须显式配置它。

我可以在 PHP 8.3 中将类型化类常量与联合类型一起使用吗？

可以。const int|string VERSION = 8; 是有效的。对象类型常量也允许使用交叉类型。唯一禁止的类型是 void 和 never。

json_validate() 和 json_decode() 在验证目的上有什么区别？

json_validate() 在不在内存中构建 PHP 值的情况下解析 JSON 结构。对于大型有效载荷，它的内存效率显著更高，当您只需要确认结构有效性时速度也更快。json_decode() 必须在您实际需要解码数据时使用——不要依次调用两者；只有当您打算丢弃结果时才调用 json_validate()。

PHP 8.3 是否支持 PHP 8.2 中引入的 readonly 类？

是的，并且进行了扩展。PHP 8.3 允许在 __clone() 中重新分配 readonly 属性，这是 PHP 8.2 中 readonly 类的主要限制。这使得不可变值对象模式无需变通方案即可完全可行。