php 5.6+ 用 … 运算符接收不定参数，打包为明确类型数组，优于 func_get_args()；必须位于参数末尾且仅一次，支持与默认参数共存，但 di 容器通常不支持自动注入。
PHP函数怎么接收不确定个数的参数
用 ... 运算符（PHP 5.6+）最直接，它把多余参数打包成数组，比老式 func_get_args() 更安全、类型更明确。
常见错误是还在用 func_get_args() 配合 call_user_func_Array() 手动转发参数，结果类型丢失、ide无法提示、静态分析失效。
-
...必须放在参数列表末尾，且只能出现一次 - 它不是“可选参数”，而是“收集剩余参数”，前面仍可定义必填参数
- 如果函数声明了类型提示（如
String ...$names），每个传入值都会单独校验类型
function log_message(string $level, string ...$parts): void { $msg = implode(' ', $parts); Error_log("[$level] $msg"); } log_message('ERROR', 'User', 'not found', 'id=123'); // ✅ log_message('WARN'); // ✅ $parts 是空数组为什么不能在PHP 5.5或更低版本里用...
因为 ... 是 PHP 5.6 引入的语法糖，低版本解析器会直接报 Parse error: syntax error, unexpected '...'。
此时只能退回到 func_get_args()，但要注意它不检查参数类型，也不参与函数签名，容易掩盖逻辑漏洞。
立即学习“PHP免费学习笔记（深入）”；
-
func_get_args()返回的是当前作用域所有参数的副本，不是引用 - 不能和命名参数混用（PHP 8.0+ 才支持命名参数）
- IDE 和 Psalm/PHPStan 对它的类型推断非常弱，容易漏掉空数组或非预期类型
function legacy_sum() { $args = func_get_args(); // 返回 array，但没类型信息 return array_sum($args); } ... 和默认参数一起用会不会冲突
不会冲突，但顺序必须严格：必填参数 → 默认参数 → ... 参数。PHP 按位置绑定，不按名称。
容易踩的坑是误以为默认参数能“跳过”，结果传少了导致 ...$rest 拿到本该是默认值的参数。
- 默认参数只在调用时未提供该位置参数才生效
-
...只捕获“多出来的”参数，不干涉前面已声明的参数绑定 - 混合使用时，调用方必须清楚每个位置对应什么，否则语义易混淆
function build_url(string $host, string $path = '/', array ...$queries): string { $url = "https://$host$path"; if (!empty($queries)) { $url .= '?' . http_build_query($queries[0]); // 注意：$queries 是数组套数组 } return $url; }PHP可变参数在反射和依赖注入里表现如何
反射（ReflectionFunction）能正确识别 ... 参数，标记为 isVariadic() === true；但大多数 DI 容器（如 symfony、laravel）不支持自动解析 ... 参数，会直接报错或跳过。
这意味着：写命令行指令、事件监听器这类需要灵活传参的场景，别指望容器自动注入 ...$options —— 得手动拆包或改用配置数组。
-
ReflectionParameter::isVariadic()是唯一可靠的运行时判断方式 - PSR-11 兼容容器基本不处理 variadic 参数，属于“用户责任区”
- 单元测试中若用
Mockery或PHPUnit模拟这类函数，需显式传入数组而非展开
函数签名里的 ... 看似简单，但一旦涉及类型约束、容器集成或跨版本兼容，细节就全浮出来了。最常被忽略的是：它生成的数组是“一维”的，而实际业务里往往需要结构化参数，这时候硬塞 ...$data 不如明确定义 array $options = []。