PHP 7.2 返回类型声明是硬性约束，getTicket() 报错因实际返回 null 而非声明的 array；需确保所有执行路径返回合规数组，包括缓存判空、异常兜底和参数校验。
直接结论：这类报错是 PHP 类型声明强制校验失败，不是语法错误，而是运行时类型不匹配。核心解决思路是让实际返回值严格符合函数签名声明的类型。
为什么 getTicket() 在 PHP 7.2 报 Return value must be of type array, null returned
PHP 7.2 的返回类型声明是硬性约束：只要函数声明了 :array，就必须返回数组；哪怕缓存层返回 null、API 调用失败没兜底、或异常分支遗漏，都会触发 TypeError。而 PHP 8.0+ 对 null 更宽容（尤其配合联合类型），所以“看起来”不报错。
常见诱因包括：
- 缓存驱动（如 Redis 或文件）读取失败时返回
null，但代码没做判空 -
$this->requestRaw()抛异常或返回非数组响应（如空响应、JSON 解析失败），但castResponseToType()没兜住 - 类型声明写在方法上，但内部逻辑存在未覆盖的分支（比如
if (...) { return []; } else { /* 没写 return */ }）
preg_match() 的 $matches 参数引发的类型不匹配
这个容易被忽略：虽然 preg_match() 声明第三个参数是 array &$matches，但它**允许传入 null（PHP 7.4+ 默认值）**，而如果你在严格模式下自己声明了类似 function foo(array &$matches): void，再把 null 传进去，就会报错。
立即学习“PHP免费学习笔记（深入）”；
更隐蔽的是 PREG_UNMATCHED_AS_NULL 标志的影响：
- 不加该标志时，未匹配捕获组填空字符串
""—— 是string，兼容array元素类型 - 加了该标志后，未匹配组填
null—— 如果你后续用foreach ($matches as $str)并假设每个$str是字符串，就可能崩在strlen(null)上，报错虽不同，但根源仍是类型契约被破坏
修复动作要落在具体位置，不是升级 PHP 就完事
升级 PHP 版本能绕过部分报错，但掩盖了逻辑缺陷。真正要改的是代码契约履约能力：
- 检查所有带返回类型声明的方法，确保 每条执行路径都有明确的、类型合规的 return（包括
catch块和else分支） - 对缓存读取结果做显式判空，例如：
if ($cachedResult === null) { return []; }或抛出业务异常，而不是依赖类型系统兜底 - 调用第三方 SDK 方法前，先看它文档是否声明了可能返回
null；如果声明了:array却实际可能null，说明 SDK 有 bug 或版本不匹配，应降级或打补丁 - 启用
declare(strict_types=1)后，连函数调用传参都要严格匹配 —— 别用json_decode($s, true)结果直接塞给期待array的函数，因为json_decode失败时返回null
最常被跳过的点：类型声明只管“出口”，不管“入口”。一个 :array 方法可以被传入 null 当参数（除非参数也加了 ?array），然后在内部 is_array() 判空后返回默认数组 —— 这种防御写法比指望调用方不传错更可靠。
