php 8.4 的 readonly 类需用 readonly class 声明，强制所有属性不可变；构造函数必须使用属性提升语法，禁止普通构造函数和非构造方法，且实例化后任何属性修改（含反射）均抛出不可捕获的 error。
PHP 8.4+ 的 readonly 类怎么用才不翻车
直接写 readonly class 很快，但翻车点集中在构造参数校验和类型穿透上。比如你传了个 null 进去，类本身不拦，等到后续调用 $dto->publishedAt->format() 才报错——这违背了“边界即刻校验”的本意。
正确做法是：在构造函数里做最小必要断言，别把校验逻辑甩给下游。
- 用
assert($publishedAt instanceof \DateTimeImmutable)或抛出InvalidArgumentException，而不是依赖 IDE 提示或文档 - 避免把数组、
stdClass或未验证的请求数据直接塞进readonly构造器；先过一层FromArray工厂方法 - 注意 PHP 8.4 的非对称可见性（
private readonly）不能用于构造属性，只能用于普通属性——否则会报ParseError: readonly property cannot be private
Composer 依赖升级卡在 dev-main 或版本冲突怎么办
2026 年很多包已转向 dev-main 分支发布新功能（尤其是工作流引擎如 tpflow/core），但你的 composer.json 锁死 "^2.1" 就会拒绝安装，报错类似：Your requirements could not be resolved to an installable set of packages.
这不是 Composer 坏了，而是语义版本策略变了：很多维护者不再维护小版本分支，只保 main 和 stable 标签。
- 临时解法：运行
composer require vendor/package:dev-main --with-all-dependencies，再手动加"minimum-stability": "dev"到composer.json（仅限测试环境） - 长期解法：改用
composer update --with-dependencies替代单包更新，让 Composer 自动推导兼容路径 - CI 中必须加
composer validate --strict，它能提前发现platform.php和实际运行时不一致的问题——这是 2026 年最常被忽略的兼容性漏网之鱼
OPcache 配置调不对，缓存命中率反而掉到 30%
很多人照抄网上旧配置，把 opcache.max_accelerated_files 设成 10000，结果项目一上微服务拆分，文件数超 15000，缓存就频繁驱逐，命中率暴跌。这不是 OPcache 不行，是没对齐真实规模。
判断依据很简单：跑一次 opcache_get_status()['opcache_statistics']['max_cached_keys']，看它是否接近你设的值。如果长期 >95%，说明要调大；如果
- 生产环境建议从
opcache.max_accelerated_files=20000起步，配合opcache.revalidate_freq=0（配合部署钩子清缓存，而非轮询） - 禁用
opcache.validate_timestamps=1在容器化部署中毫无意义——镜像构建后代码不会变，开它只会徒增 stat 系统调用 - 别信“越大越好”：
opcache.memory_consumption=512对多数中小项目是过载，256MB 更稳，留内存给 Redis 或 DB 连接池更实在
DTO 边界不设防，null 一路透传到数据库层
重构老项目最痛的不是语法，是数据流失控。比如一个 CreateOrderInput DTO 允许 public readonly ?string $couponCode，但业务规则明明要求“有优惠券就必须校验有效性”，而校验逻辑却散落在 Service 层深处——结果前端传 {"couponCode": null}，后端照样走通，直到插入时触发 NOT NULL 约束失败。
边界的意义不是“能装”，而是“该拦的必须拦住”。2026 年的实践是：DTO 只接收确定有效的原始值，不确定的交给专门的 ValidationContext 处理。
- DTO 构造器里不做远程校验（比如查 Redis 是否有效券），只做本地结构检查（长度、格式、非空）
- 把
?string换成string+ 显式默认值（如空字符串），或用Option<string></string>类型（需自建或引入spatie/optional） - Controller 层收到请求后，立刻转成 DTO；之后所有 Service、Repository 调用都只认 DTO，不接受
array或Request对象——这是防止“临时绕过”最硬的防线
真正卡住效率的，往往不是语法多难，而是边界模糊带来的反复确认。每次你犹豫“这个 null 是允许的吗”，就是在为未来埋一个需要三个人协同调试的 bug。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
