PHP未死，但必须采用PHP 8.3+的strict_types=1、readonly类、类型化输入边界、固定镜像版本、自动化工单兼容检查等现代实践来保障协作效率与线上稳定性。
PHP没死，但老写法已经扛不住2026年的协作节奏和线上稳定性要求。真正能落地的“现代实践”，不是堆砌新语法，而是用类型、边界和自动化把不确定性锁死。
PHP 8.3+ 的 strict_types 和 readonly 类必须开
不加 declare(strict_types=1)，int 参数声明就形同虚设；不用 readonly class，DTO 就是带类型注解的数组——运行时照样崩在 Call to a member function format() on null。
- 所有新写的 DTO、VO、Request 类，强制用
readonly+ 构造器参数提升（PHP 8.2+） -
strict_types=1必须写在每个 PHP 文件顶部，不能只靠 IDE 提示或 Psalm 静态分析兜底 - 框架层（如 Laravel 的
FormRequest）也要手动映射为readonly对象，别让验证规则和类型声明脱节
输入边界必须在 Controller 层就收口
“数据边界”不是架构图里的虚线，是代码里第一个 new 出来的对象。一旦让 $_POST 或 JSON body 在 service 层裸奔，array_key_exists('status', $input) 就会变成线上告警的起点。
- Controller 中禁止直接操作
$_GET/$_POST，统一走Request对象或readonlyDTO 实例化 - 第三方 API 响应、队列消息体、文件上传元信息，同样要立刻转成类型化对象，而不是传
array或stdClass - 用
match替代长串if-else处理状态映射，避免漏分支导致null流入下游
Docker 镜像里禁用 dev 依赖，且必须固定 PHP minor 版本
CI 跑通、本地跑挂，八成是 php:8.3 镜像拉到了 8.3.12，而你本地装的是 8.3.5——JIT 行为、Opcache 优化策略、甚至 DateTimeImmutable 解析精度都可能有细微差异。
立即学习“PHP免费学习笔记（深入）”；
- Dockerfile 中明确写死
FROM php:8.3.5-cli-slim，不要用8.3或latest -
composer install必须加--no-dev --optimize-autoloader，镜像里不装phpunit、faker、symfony/var-dumper -
.env中的PHP_VERSION与镜像标签一致，并在启动脚本里做校验：if [ "$(php -v | head -1 | cut -d' ' -f2)" != "8.3.5" ]; then exit 1; fi
升级不是“改完再测”，而是每周跑一次 composer update --dry-run
等项目卡在 PHP 8.1 上三年才升，等于主动放弃 enum、never、属性钩子这些能消灭空指针和非法状态的工具。真正的升级成本不在改代码，而在没建立反馈闭环。
- CI 流水线里加一个
php8.4-compat任务，只跑phpstan+phpcs，不跑测试，失败不阻断主流程 - 本地开发用
phpbrew或asdf管理多版本，每天切一次8.4运行php -l扫单文件 - Composer 的
platform配置必须锁定："config": {"platform": {"php": "8.3.5"}}，否则require里写^8.3也没用
最常被跳过的一步：把 DateTimeImmutable 当作默认时间类型，而不是留到出 bug 再补。它不光防时区错乱，更防你在异步消费消息时，被同一个 DateTime 实例在多个协程里反复 modify()。
