func_num_args() 在闭包中报错，因它仅支持普通函数或方法上下文，依赖调用栈信息；PHP 8+ 更严格，直接触发 Fatal error。
为什么 func_num_args() 在闭包里会报错
因为 func_num_args() 只能在「普通函数」或「方法」内部调用，它依赖 PHP 的运行时函数调用栈信息。闭包（anonymous function）不被视为传统函数上下文，直接调用会触发 Warning: func_num_args(): Called from the global scope 或更严格的 Fatal error（PHP 8+）。
实操建议：
- 闭包中要动态获取参数数量，改用
...$args可变参数语法，然后用count($args) - 如果必须复用旧逻辑，把闭包逻辑抽到命名函数里，再在闭包中调用它
- PHP 8.0+ 可配合
ReflectionFunction检查参数，但开销大，仅调试用
func_get_args() 和 func_num_args() 必须成对出现
这两个函数是绑定的：只要用了 func_num_args()，就必须在同一作用域内调用 func_get_args()（哪怕你只想要个数量）。否则 PHP 可能缓存错误的参数列表，尤其在递归或嵌套调用时，返回的数字和实际传入的不一致。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 函数接收 3 个参数，
func_num_args()却返回 1 - 后续调用
func_get_args()得到空数组或截断数据
正确写法示例：
function log_args() {
$n = func_num_args(); // 必须先调这个
$args = func_get_args(); // 紧接着调这个
echo "共 $n 个参数：";
print_r($args);
}
PHP 7.4+ 中可变参数 + 类型声明让 func_num_args() 更少必要
有了 ...$args 语法和严格类型声明，多数场景不再需要 func_num_args() 做“兜底判断”。硬用反而容易出错——比如你写了 function foo(string $a, ...$rest)，但还在里面调 func_num_args()，那它返回的是总参数数（含 $a），而 $rest 只包含额外部分，两者不等价。
使用场景建议：
- 维护老代码、无法改签名时保留
func_num_args() - 做兼容性桥接（如同时支持 PHP 5.6 和 8.2 的库）
- 写函数装饰器或 call_user_func 类封装时需精确判断调用者传了几个参数
性能影响：几乎可忽略，但比直接用 count($args) 略慢一点（毕竟要查栈帧）
在重载方法（__call）里用 func_num_args() 要小心参数偏移
__call 的第一个参数是方法名（$name），第二个才是参数数组（$arguments）。如果你在 __call 里误调 func_num_args()，它返回的是 __call 自身被调用时的参数总数（即 2），而不是目标方法该收几个参数。
容易踩的坑：
- 以为
func_num_args()能反映“被代理方法期望的参数个数”，其实不能 - 混淆
func_num_args()和count($arguments)：后者才是实际传进来的参数数量 - 没检查
$arguments是否为数组就直接count()，PHP 7.2+ 会 warning
正确做法是直接用 count($arguments)，或通过 new ReflectionMethod($this, $name) 查目标方法的 getNumberOfParameters()
最麻烦的地方不是语法记不住，而是它依赖调用栈上下文——一旦混进 call_user_func、eval、匿名函数或者 __call，行为就容易偏离直觉。真要用，先确认当前函数是不是被明确调用的、非动态生成的普通函数。
