php 8.0联合类型要求显式穷举所有可能类型，漏写|null等常见情形将导致运行时typeerror；参数、返回值、属性均需严格覆盖实际值域，且不自动转换类型。
PHP 8.0 的联合类型不是“能用就行”，而是必须显式声明所有可能类型，否则运行时直接 TypeError。尤其当值可能为 null 时，漏写 |null 是线上崩溃最常见原因。
函数参数必须覆盖所有实际传入类型
联合类型在运行时做硬校验，不匹配就中断执行。不能靠文档或注释“暗示”可选类型。
- 错误写法：
function getName(string $name)—— 若调用方传null或int，立刻报错 - 正确写法：
function getName(string|int|null $name)，按实际逻辑穷举 - 如果只接受字符串或空值，写
string|null；若还可能传0或''，就得加|int|bool并在函数内做语义判断 - IDE 和 PHPStan 能识别联合类型，但不会帮你补漏——它们只检查你写的是否自洽，不验证你是否写全
返回值类型必须与所有分支路径一致
PHP 不做控制流分析，只看最终 return 表达式的静态类型是否落在声明范围内。
- 错误示例：
function findUser(int $id): User { return $id === 1 ? new User() : null; }——null不在User类型中，运行时报TypeError - 正确写法：
function findUser(int $id): User|null，且调用处必须主动检查if ($user !== null) - 避免用
?User混淆：虽然等价于User|null，但在复杂联合中（如User|Admin|null）必须展开写，否则语义模糊 - 返回
array|false（如旧版mysqli_fetch_array）要显式声明，不能依赖历史习惯
类属性声明需配合构造器/赋值逻辑
属性联合类型是“承诺”，不是“建议”。一旦声明，所有写入路径都必须满足。
- 错误写法：
class Config { public string|array $data; }，但构造器里只赋了string，后续业务代码却写了$config->data = []—— 运行时不报错，但静态分析会告警，且违反契约 - 正确做法：属性声明与初始化、setter、JSON 解码等所有写入点对齐。例如数据库模型字段可能为
string|null，那就确保 ORM 映射和手动赋值都兼容 - 不要为“暂时不确定”而滥用
mixed或object—— 联合类型的价值正在于缩小不确定性，而不是掩盖它 - 属性类型不能含
void，也不能是纯null（null必须与其他类型联合）
别把联合类型当类型转换开关
联合类型不改变值本身，也不触发自动转换。它只是运行时的守门员。
-
function parse(int|string $input): float { return $input * 1.1; }—— 若传"123"，PHP 不会自动转成int，而是走字符串乘法（结果为0.0），逻辑出错但类型不报错 - 真正安全的做法是：先用
is_int()/is_string()分支处理，再分别 cast 或抛异常 - 联合类型 + 严格模式（
declare(strict_types=1)）才能堵住隐式转换漏洞；单用联合类型，只是把错误从“静默失败”变成“运行时报错” - 性能上无额外开销——类型检查只在函数入口/出口发生，不遍历值内容
最易被忽略的一点：联合类型声明后，你承担了完整类型契约责任。它不帮你推理业务逻辑，也不替你写空值检查。写 string|null 就意味着你必须在每个使用点确认非空，否则 strlen(null) 还是会崩——类型系统只管声明，不管执行。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
