联合类型使php运行时强制校验参数类型，如int|string在函数入口检查并抛typeerror，不支持隐式转换，提升类型安全但不解决值逻辑错误。
因为联合类型把“可能的类型”从注释搬进函数签名，PHP 运行时会真校验，不匹配直接报 TypeError，而不是靠人肉判断或后期崩溃。
联合类型让参数校验从「可选」变成「强制」
PHP 7.x 时代，若函数想同时接受 int 和 string，只能用 mixed 或靠文档说明，实际传入 null、array 甚至 resource 都不会在调用时拦住——错误被推迟到内部逻辑出问题才暴露。
PHP 8.0 后，写成 function handleId(int|string $id)，运行时会立刻检查：$id 是 int？是 string？都不是就抛 TypeError。这个检查发生在函数入口，不依赖你写没写 is_int() 或 is_string()。
- 不支持隐式转换：传入字符串
"123"给int|string是合法的；但传入"abc"给int单独声明会失败，而联合类型仍只认字面类型，不会自动 cast -
strict_types=1下更严格：关闭弱类型转换，避免"42"被当成int的侥幸行为 - IDE 和静态分析（如 PHPStan）能基于联合类型做路径推导，提前标出
if (is_int($id)) { $id->method() }这类误用
为什么 int|float 比 float 更安全
很多数值处理函数习惯声明 float 参数，以为能兼容整数——但 PHP 的类型系统不会自动把 int 当 float（尤其开启 strict_types 后）。结果就是：传 42 进去，直接 TypeError。
改成 int|float 后，两种都合法，且语义清晰：这个函数本就设计为处理整数或浮点数，不是“我随便收一个数字，你别管我怎么用”。
- 常见翻车点：
json_decode($json, true)返回array|null，如果函数参数只写array，null进来就崩；必须显式写成array|null - 数据库查询结果常是
stdClass|false，过去靠if ($row)判断，现在类型声明本身就能约束输入来源 - 不要省略
null：string≠string|null，后者必须显式写出，否则null传入直接报错
联合类型不解决「值逻辑错误」，只解决「类型错配」
它不会阻止你传一个 string 类型的非法 ID（比如空字符串、超长字符串），也不会校验数组结构是否符合预期。它的作用边界很明确：只管「这个变量是不是你声明的那几种类型之一」。
- 该用
filter_var()做值校验的地方，不能指望联合类型代劳 - 对
array类型，联合类型不检查键名或子元素类型；要精确约束得用array<string int></string>（PHP 8.1+）或对象封装 - 当联合类型中含
object，PHP 不校验具体类名，只检查是否为对象实例；需配合instanceof或接口约束
最易被忽略的是：联合类型本身不提供运行时类型收窄能力。你写了 int|string，PHP 不会自动帮你区分当前是哪种——if (is_int($x)) { ... } 还得自己写，不然调 $x->method() 就崩。类型声明只是守门员，进门后的逻辑安全，还得靠你亲手把关。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
