php 8 中 implode() 等内置函数参数类型变严格，传非数组给 implode() 第二个参数会直接抛出 typeerror 致命错误而非警告，需在调用前用 is_array() 检查或提供空数组兜底。
不改函数调用方式，PHP 8 会直接抛 TypeError 中断执行——不是 warning，不是 notice，是 fatal。
内置函数参数类型变严格了，传错就崩
PHP 8 对大量内置函数的参数类型做了强制校验，老代码里“凑合能用”的写法全失效。常见崩点：
-
array_key_exists()第二个参数必须是array或ArrayObject，传null、string或未初始化的$_GET变量，直接Fatal error: Uncaught TypeError -
json_decode()第二个参数$assoc必须是bool，传1、'true'或0全报错，得统一改成true或false -
preg_replace()的$limit参数禁用负数，传-1（常用于“不限次数替换”）会 fatal，需改用-1以外的大整数如PREG_REPLACE_LIMIT或逻辑重写 -
mb_strpos()第三个参数$offset不再接受float，round(strlen($s)/2)若上游混入浮点运算，结果可能是5.0，就得显式转成(int) $offset
字符串函数参数顺序被重排，调用即错
PHP 8 按 RFC 统一了字符串函数参数顺序，部分函数签名已变，调用时参数位置错位会导致逻辑错误或 fatal：
-
strstr()从(needle, haystack)改为(haystack, needle)，旧写法strstr('x', 'hello')在 PHP 8 返回false（因为把'x'当作 haystack 查找），但更危险的是它可能被误判为“没找到”，掩盖问题 -
stristr()、strrchr()等未改，但混用时极易出错；建议全局搜索strstr\(、stristr\(并逐个验证参数顺序 - 别依赖 IDE 自动补全——很多旧版插件仍按 PHP 7 签名提示，补全后实际运行就挂
函数返回值类型不匹配，不再是 warning
PHP 8 把“返回类型声明不满足”从 runtime warning 升级为 TypeError，尤其在 ORM 或工具类中高频踩坑：
- 定义了
function getId(): int，但数据库字段允许 NULL 且没设默认值，实际返回null→ 直接 fatal -
get_class(null)在 PHP 7 返回false，PHP 8 抛TypeError，框架反射层常用这种守卫逻辑，升级后初始化就中断 -
strlen(null)、mb_strlen(null)、trim(null)等，以前返回0或空字符串，现在一律TypeError；所有外部输入（$_POST、JSON 解析结果、DB 查询字段）进这些函数前必须先判空
命名参数混用被禁止，语法层面拒绝执行
PHP 8 禁止位置参数和命名参数混写，这不是运行时错误，是 ParseError，连脚本都加载不了：
-
greet("World", greeting: "Howdy")→ParseError: syntax error，哪怕函数本身支持命名参数也不行 - Laravel 的
Validator::make($data, $rules, $messages)若写成Validator::make($data, rules: $rules)，第三个参数缺失，但混写语法本身已非法 - 修复方法只有两种：全用位置参数（
make($data, $rules, $messages)），或全用命名参数（make(data: $data, rules: $rules, messages: $messages)）；不能过渡，没有兼容层
最麻烦的不是报错本身，而是有些函数（比如 array_key_exists()）在开发环境因变量恰好有值而“侥幸通过”，一到生产环境遇到空数据就崩——这类问题必须靠真实数据集触发，光跑单元测试不够。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
