PHP 8 混合类型与 Never 返回类型解析

PHP 8 的 `mixed` 和 `never` 并非灵活搭档，而是语义截然对立、各司其职的类型契约工具：`mixed` 表示“输入类型完全不可控，必须依赖运行时判断”，仅适用于序列化入口、API 响应解包等真正无法约束的场景，滥用它掩盖设计缺陷；而 `never` 是数学意义上的空集类型，声明“函数绝对不返回”，一旦使用就必须确保所有路径无条件终止（throw/exit/die），混入联合类型或仅“可能抛异常”都会破坏契约、引发致命错误。二者在错误处理链中常共存——一个放行不确定输入，一个堵死所有出口——但稍有疏漏（如分支遗漏、伪终止、缺少类型断言）就会让静态分析失效、运行时崩溃悄然潜入。它们不降低复杂度，只是把逻辑完整性责任前置到签名与检查阶段：写对类型，远不如想清控制流重要。

mixed 和 never 不是互补搭档，而是各守一端的类型契约工具：前者表示“类型未知但允许运行时判断”，后者表示“根本不会返回任何值”。混用或误判语义，比不写类型更危险。

什么时候该用 mixed，而不是省略类型？

仅当函数必须接收任意原始输入、且无法在签名层做任何约束时才用 mixed——典型场景是序列化入口、通用缓存包装器、调试日志记录器。

• 外部 API 响应解包（如 json_decode($raw, flags: JSON_THROW_ON_ERROR) 返回值必须标注 mixed，因为结构完全由上游决定）
• 框架中间件的 handle(mixed $request)，因请求对象可能被运行时替换为不同实现
• 避免把 mixed 当“懒人占位符”：比如 function filter($data) 改成 function filter(mixed $data) 并不增强安全，只是掩盖了本该明确的 array|string 约束
• PHPStan/PSALM 会将未标注的参数默认视为 mixed，但显式写出能触发更早的类型检查路径，尤其在泛型推导中

为什么 never 不能和任何类型联合？

never 是空集类型（∅），数学上 ∅ ∪ T = T，所以 never|string 在语义上等价于 string，直接破坏“永不返回”的断言。PHP 8.1 会报 Fatal error: never can only be used as a standalone type。

• 合法用法只有 function abort(): never 或 function throwIf(bool $cond): never
• 常见错误：把“可能抛异常”的函数标为 never，例如数据库查询封装里只写了 if (!$result) throw new RuntimeException(...)，但没处理 $result === false 后继续执行的分支——这会让静态分析误以为所有路径都终止，实际却可能返回 false
• 继承时，父类声明 void，子类可覆盖为 never（强化契约）；但父类是 never，子类绝不能改成 string 或 void（违反协变）

mixed 和 never 在真实错误链中的协作陷阱

二者常出现在同一调用栈，但角色截然相反：一个放行不确定输入，一个堵死所有出口。最容易出问题的是“兜底逻辑”。

• 示例：一个 processInput(mixed $input): string 函数内部做了 if (is_array($input)) { ... } 分支，但漏掉 else 处理非数组情况——此时 PHP 不会自动补 return，而如果末尾没写 throw 或 exit，就违反了 string 返回契约；若你试图用 never 标记这个“兜底分支”，必须确保它真能终止流程（throw / exit / die），否则就是假 never
• mixed 输入 + never 输出组合，往往意味着“只要输入不符合预期，立刻炸”，比如配置加载器：function loadConfig(mixed $config): never 只应在验证失败时无条件 throw，不能留任何静默 fallback
• PHPStan 默认对 mixed 的控制流分析较弱，若你在 mixed 分支里写了 never 路径，需配合 @psalm-assert 或类型断言，否则仍可能漏检

最易被忽略的点：类型系统不替你保证逻辑完整性。mixed 不代表“随便传”，never 不代表“写了就不会错”——它们只是把责任从运行时提前到签名层和静态检查阶段。一旦分支覆盖不全或异常未真正抛出，契约就形同虚设。

今天关于《PHP 8 混合类型与 Never 返回类型解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！