TypeError报错并非PHP 8.5.7新增，而是旧代码隐患在更严格类型校验下暴露；declare(strict_types=1)开启后强制参数与返回值精确匹配，禁止字符串转int、null当string等隐式转换，需补全类型检查而非关闭严格模式。
TypeError 报错不是 PHP 8.5.7 “新加”的，而是你代码里早就有隐患，升级后更严格的类型校验把它揪出来了。
declare(strict_types=1) 是开关，不是装饰
这个声明一旦开启，就强制所有函数调用必须严格匹配参数和返回类型——字符串不再自动转成 int，null 也不再被当作 string 接受。 常见踩坑点： -declare(strict_types=1) 写在文件顶部，但只对当前文件生效；有些文件开了，有些没开，导致行为不一致
- 函数定义写了 function foo(int $id): string，但调用时传了 "123"（字符串）→ 直接抛 Fatal error: Uncaught TypeError
- 返回值用了 return $result ?? ''，但声明是 : int → null 或空字符串都不行
参数类型声明和实际传入值不匹配
PHP 8.5.7 不再静默转换，尤其在 strict mode 下： -json_decode($json) 返回 null 或 array，若函数签名要求 array 却没做判空，就会崩
- $_GET['id'] 拿到的是字符串，直接传给 function getPost(int $id) 就报错
- 使用 ?? 或 ?: 时，右侧默认值类型可能和声明冲突，比如 int|null 声明却写了 return $x ?? "0"返回类型协变/逆变没对齐
子类重写父类方法时，返回类型必须兼容（PHP 7.4+ 引入，8.5.7 执行更严）： - 父类方法声明function find(): User，子类写成 function find(): ?User 是允许的（协变）
- 但如果子类写成 function find(): object 或 function find(): array，就会触发 Return type ... should be compatible with
- 第三方库（如旧版 Doctrine、Symfony 组件）常有这类问题，不能只改自己代码，得看 composer why-not php:8.5 锁定具体包
容易被忽略的“隐性”类型陷阱
-foreach 遍历一个可能为 null 的变量，而循环体里又调用了带类型声明的函数
- filter_var($_POST['email'], FILTER_VALIDATE_EMAIL) 返回 false，但后续当 string 用
- 使用 is_numeric() 判定后仍直接传给 int 参数，忽略了它对 "12.3" 也返回 true，但 (int)"12.3" 是 12，而 strict mode 下不允许传入
真正要动的不是“关掉 strict”，而是补全类型检查、加断言、用 match 替代松散比较、把 ?? 右侧值显式 cast 成目标类型——否则下次升级，问题只会更早暴露。
