PHP 8.4未新增strict_types行为，但强化了自7.0起逐步收紧的类型校验逻辑，使原有混合声明、隐式转换等隐患集中暴露；需统一项目策略、扫描全量声明、配合PHPStan检测并规范使用。
PHP 8.2 升级到 8.4 后，declare(strict_types=1) 相关报错不是新问题，而是原有隐患在更严格环境下的暴露。8.4 本身没有新增 strict_types 行为，但它继承并强化了从 7.0 起逐步收紧的类型校验逻辑——尤其当项目中混合了声明与未声明 strict_types 的文件、或存在隐式类型转换依赖时，错误会集中浮现。
检查 strict_types 是否被跨文件污染
strict_types 是**文件级**指令，只对当前文件生效。但常见错误是：A.php 声明了 strict_types=1，却引入了 B.php（未声明），而 B.php 中定义的函数又被 A.php 调用。此时，A.php 调用 B.php 函数时仍走弱类型逻辑；但若 B.php 内部又调用了 C.php（声明了 strict_types=1）的函数，类型校验边界就变得模糊，容易触发意外 TypeError。
- 用
grep -r "declare(strict_types=" . --include="*.php"扫描全项目，确认每处声明是否意图明确 - 重点检查 Composer 自动加载的 vendor 文件——第三方库若未声明 strict_types，你的 strict 文件调用它时不会强制校验，但若你给参数传了不匹配类型，错误可能延迟到运行时才抛出
- 避免在同一个命名空间下混用 strict 和非 strict 文件定义同名函数，PHP 不会报错，但行为不可控
修复典型 strict_types 报错场景
升级后最常见的 TypeError 都围绕参数/返回值类型不匹配。8.4 并未新增类型规则，但因底层引擎优化和 JIT 行为变化，某些原本“侥幸通过”的弱类型调用会更早失败。
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
-
字符串数字传给 int 参数：如函数声明
function foo(int $x) { }，调用foo("123")在 strict 模式下直接报 TypeError。改法：显式转换foo((int)"123")或改用filter_var("123", FILTER_VALIDATE_INT) -
null 传给非可空类型：如
function bar(string $s) { }接收了null。必须改为function bar(?string $s) { }，并在函数内做if ($s === null)判断 -
数组键访问未校验：如
$arr['missing'] ?? ''在 strict 模式下安全，但$arr['missing']直接访问会触发 Notice（非 Fatal），不过若该数组来自弱类型函数返回，且你把它当作 string 传给 strict 函数，就会连锁报错
统一项目类型声明策略
不要让 strict_types 成为“补丁式”存在。要么全项目启用，要么全关闭。混合使用会大幅增加维护成本和出错概率。
立即学习“PHP免费学习笔记（深入）”；
- 新建文件默认加
declare(strict_types=1);，作为团队规范写入代码模板 - 对历史代码，用 PHPStan 级别 7 或 Psalm 级别 3 扫描，它能精准标出哪些函数调用违反 strict 规则，比靠报错日志定位高效得多
- CI 流程中加入
php -l+phpstan analyse --level=7，确保每次提交都过严格类型检查
注意 8.4 新增特性与 strict 的交互
PHP 8.4 引入的属性钩子（property hooks）、只读类（readonly classes）等特性本身不改变 strict_types 行为，但它们常与类型声明配合使用，容易放大原有问题。
- 例如定义
readonly public int $id;，若构造时传入"1"字符串，即使没开 strict_types，8.4 也会报 TypeError——因为 readonly 属性初始化阶段就执行类型校验 - 属性钩子中的
__set()方法若声明了public function __set(string $name, mixed $value): void，但实际赋值的是int，同样触发 strict 报错 - 建议：所有带类型声明的钩子方法、只读属性、枚举成员，都配套加上
declare(strict_types=1)，保持语义一致
