php 8.4 的 readonly 类必须在构造函数中一次性赋值，禁用框架自动注入，改用手动实例化与静态工厂方法；opcache.preload 与 jit 强耦合，需绝对路径加载、禁用运行时判断、避免全局状态；nginx + php-fpm 是2026年唯一合理生产组合，须关闭 fastcgi_buffering、慎用 static 模式、对齐日志配置；composer 升级失败多因 platform 锁定过旧、缓存污染或 preload 中未声明 use。
PHP 在 2026 年不是“还能用”，而是“更该用”——前提是抛弃 PHP 7 时代的惯性写法，把 readonly、enum、opcache.preload 和 PHP-FPM 调优当作基础配置，而不是进阶技巧。
PHP 8.4 的 readonly 类怎么用才不翻车
很多人一上手就写 readonly class，但立刻在框架里报错：Property access is not allowed on readonly class。问题不在语法，而在生命周期和赋值时机。
- readonly 属性必须在
__construct()中一次性赋值，不能延迟初始化（比如在 setter 或 init 方法里） - 框架如 Laravel 的
fromRequest()或 ThinkPHP 的自动注入，会尝试反射赋值，直接绕过构造函数——此时需显式禁用自动绑定，改用new ArticleDTO(...)手动实例化 - DTO 传参时别再用
array_merge($defaults, $input)，改用ArticleDTO::fromArray($input)静态工厂方法做类型校验和默认值兜底 - 配合
declare(strict_types=1)使用，否则string字段可能被悄悄转成int导致 readonly 失效
opcache.preload + JIT 组合启用的硬性条件
opcache.preload 不是加一行配置就能生效的开关，它和 JIT 是强耦合关系。很多团队开了 opcache.jit=1255 却没提速，根本原因是 preload 文件里存在未解析的类引用或动态 require。
- preload 文件必须用绝对路径加载，且所有被
require_once的文件都得在 preload 阶段可访问（不能依赖运行时__DIR__动态拼接） - JIT 缓冲区大小必须 ≥ preload 加载后 OPcache 内存占用的 1.5 倍，否则 JIT 自动降级；可用
opcache_get_status()['jit']['buffer_free']实时查剩余空间 - preload 文件中禁止出现
function_exists()、class_exists()等运行时判断，这些会阻断 JIT 编译链 - FPM 模式下，preload 只在 master 进程加载一次，worker 进程共享——所以 preload 里不能有全局状态（如
static $counter = 0）
为什么 Nginx + PHP-FPM 是 2026 年生产环境唯一合理选择
Apache 的 mod_php 在 PHP 8.4 下已实质废弃：它的进程模型无法利用 JIT 的长生命周期优化，且 .htaccess 动态重写在高并发下成为性能黑洞。Nginx + PHP-FPM 不是“折中方案”，而是架构刚性需求。
- Nginx 必须关闭
fastcgi_buffering off，否则大文件下载或流式响应会卡住 FPM worker - PHP-FPM 的
pm = static模式在容器中慎用——若容器内存限制为 512MB，pm.max_children = 20会导致 OOM Kill，应改用pm = dynamic并设pm.max_requests = 500防止内存泄漏累积 - 关键配置项必须对齐：
php_admin_value[error_log] = /var/log/php-fpm/www-error.log和 Nginx 的error_log /var/log/nginx/error.log warn日志级别要一致，否则 502 错误时只能看到 “upstream prematurely closed connection”，找不到真实 PHP fatal error - 别在 Nginx 配置里写
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name——2026 年主流镜像已默认启用security.limit_extensions = .php，多余参数反而触发安全拦截
Composer 依赖升级失败时最该查的三处地方
升级到 PHP 8.4 后 composer update 报错，90% 的情况不是包不兼容，而是本地环境残留了旧约束或缓存污染。
- 检查
composer.json中的"platform": {"php": "8.3.0"}是否锁死版本——这会让 Composer 忽略 PHP 8.4 的新特性支持，应改为"php": "^8.4" - 运行
composer clear-cache后，再删掉vendor/composer/installed.json，否则 Composer 会复用旧的 lock 文件解析结果 - 某些包（如 oldsymfony/console）在 8.4 下因
__toString()返回类型变更而崩溃，错误信息藏在composer diagnose输出末尾的 “Platform check” 小节，不是主错误堆栈里
真正卡住团队的从来不是语法升级，而是 preload 文件里一个未声明的 use、Nginx 配置中多出的一行 fastcgi_param、或者 Composer platform 锁定比实际运行版本低了半个 minor 版本——这些细节在文档里不会标红，在报错日志里也不会直接提示。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
