PHP框架审计中需确认PHP 8.1+及strict_types启用，再用grep定位never函数并验证仅含throw/exit/die/死循环，结合PHPStan level 8或插桩检测实际出口，最后检查接口never声明与实现是否一致。
在PHP框架审计中识别Never返回类型是否被正确使用，直接关系到异常处理逻辑是否完整、错误路径是否可控。如果Never类型标注的函数实际可能正常返回，就会导致后续代码执行路径误判，掩盖真实漏洞。
确认目标框架是否启用PHP 8.1+及Strict Types
打开项目根目录下的composer.json，检查"php": "^8.1"或更高版本声明；再查看入口文件（如public/index.php）顶部是否有declare(strict_types=1);。没有这两项，Never类型本身不会触发引擎级校验，所有分析都失去基础约束。
这一步跳过会导致后续所有类型推导失效——PHP 8.0及以下版本根本不认识never关键字，解析器会直接报错或忽略。
定位所有标注为never的函数与方法
在终端执行：grep -r "function.*: never" app/ src/ --include="*.php" | grep -v "vendor/"。
立即学习“PHP免费学习笔记（深入）”；
注意：不要依赖IDE全局搜索: never，部分编辑器会把注释里的never也匹配进来，造成误报。
手动验证每个结果：打开对应文件，确认该函数体内是否**仅包含throw、exit、die或无限循环**，且无任何return语句（包括隐式return）。
静态分析Never函数的实际控制流出口
方法一：用PHPStan level 8扫描
运行phpstan analyse --level=8 --no-progress app/ src/，重点查看输出中含Function .* should never return but does的行。PHPStan会在CFG（Control Flow Graph）层面模拟每条执行路径，比人工肉眼更可靠。
方法二：手动插桩验证（适用于关键路径）
在never函数末尾（throw之前）临时插入echo "UNREACHABLE"; die();，然后触发该函数调用。如果看到输出，说明存在未被捕获的执行路径——比如某个条件分支遗漏了throw，或try-catch吞掉了本应冒泡的异常。
【必须删除插桩代码】，否则上线后会导致服务中断。
检查Never类型在接口契约中的传播效应
第一步：找到声明function xxx(): never的接口（如Contracts/ExceptionHandler.php）。
第二步：用IDE“查找实现”功能，列出所有实现类中对应方法的签名。
第三步：逐个打开实现方法，确认其内部是否真正满足never语义——例如Laravel的Illuminate\Contracts\Debug\ExceptionHandler::report()标注为never，但其实现类Handler.php中该方法体为空，违反never契约，必须修正为throw new RuntimeException('Not implemented')或直接移除never标注。
接口层标注never而实现层未强制执行，会导致依赖该接口的组件做出错误假设，进而跳过安全校验。
