func_get_args() 在 PHP 8.5.7 中行为未变，仍返回实参副本数组，不受 strict_types 影响；所谓“类型严格”源于函数声明的类型检查在入口处拦截，而非该函数本身抛错。
func_get_args() 本身没变严格，是调用上下文变了
func_get_args() 函数行为在 PHP 8.5.7 中**没有修改**——它依然返回一个包含实参值的数组副本。所谓“类型变严格”，其实是你调用它的那个函数启用了 declare(strict_types=1)，而该声明影响的是函数参数接收环节，不是 func_get_args() 的执行逻辑。
换句话说：你看到的“类型错误”根本不在 func_get_args() 里抛出，而是在函数入口校验阶段就中断了，func_get_args() 根本没机会运行。
- 如果函数签名写了
function foo(int $a, string $b)且文件顶部有declare(strict_types=1)，传入foo("123", 456)会直接报Fatal error: Uncaught TypeError - 此时
func_get_args()还没被执行，连函数体都没进 - 只有参数通过了严格类型检查，控制流才会到达函数体内，
func_get_args()才会被调用
func_get_args() 返回值类型不受 strict_types 影响
func_get_args() 返回的永远是 array，里面每个元素的类型就是你传进去的实际类型（int、string、null、object 等），它不做任何类型转换或拦截。strict_types 对它完全无感。
常见误判场景：
立即学习“PHP免费学习笔记（深入）”；
- 你以为
func_get_args()把字符串 "123" 自动转成 int → 实际上它原样存着字符串，后续 foreach 里用+$num才可能触发隐式转换（但 strict_types 不管这个） - 你在 strict 模式下写
function bar(...$args): int，然后对$args做array_sum($args)→ 错误来自array_sum内部处理非数字值，不是func_get_args()的问题 - 用
func_get_args()获取参数后，再手动调用另一个 strict 函数（如strlen($args[0])），而$args[0]是 int → 这时才真正触发 strict 报错，但根源是strlen的参数约束
PHP 8.5.7 下 func_get_args() 的真实兼容性风险点
真正要注意的不是类型，而是调用方式和语义变化：
-
func_get_args()在命名参数（named arguments）场景下会忽略未传的命名参数，只返回实际传入的位置参数值（PHP 8.0+ 行为），容易导致你误判参数个数 - 若函数参数含引用（
&$x），func_get_args()返回的是值副本，**无法反映引用修改后的结果** —— 这在 strict 模式下更容易暴露逻辑漏洞 - PHP 8.5.7 已移除
each()等旧函数，如果你在func_get_args()后用while (list(, $v) = each($args))，会直接报Fatal error: Uncaught Error: Call to undefined function each() - 高并发下频繁调用
func_get_args()（尤其在循环里）性能开销比...语法明显，PHP 8.5.7 编译器对后者做了更多优化
替代方案：优先用 ...$args 语法
PHP 7.4+ 引入的 ... 可变参数语法，既更安全又更高效，且天然适配 strict_types：
-
function sum(...$numbers): int { return array_sum($numbers); }——$numbers类型明确是array，元素类型由调用方决定，函数内可做is_int()校验 - 不会像
func_get_args()那样绕过参数类型声明（比如你写function foo(string ...$parts)，PHP 就会在入口强制每个参数都是 string） - 支持解包：
sum(...$arr)直接展开，无需call_user_func_array() - 静态分析工具（PHPStan/psalm）能准确推导
...参数类型，对func_get_args()则基本无法识别
除非要兼容 PHP func_get_args() —— 它不是被“变严格”，而是被时代架空了。真正要盯住的，是你自己是否在 strict 模式下写了不严谨的参数处理逻辑。
