app()->make()的第二个参数必须是关联数组且键名严格匹配构造函数参数名，不支持索引数组、键名不匹配、嵌套对象或闭包，laravel 9+ 中该参数已标记为@internal，不建议业务代码依赖。
make第二个参数怎么传数组">
app()->make 的第二个参数必须是关联数组，且键名需与构造函数参数名完全一致
Laravel 的 app()->make() 默认只接受服务名（字符串）作为第一个参数，第二个参数是可选的 $parameters，用于覆盖依赖注入时的构造参数。但它**不是任意数组都能传**——必须是关联数组，且 key 必须严格匹配目标类构造函数中形参的变量名。
常见错误现象：
传入索引数组（如 [1, 'foo']）会直接报错 Too few arguments to function；传入 key 不匹配的关联数组（如 ['name' => 'xxx'] 但构造函数参数叫 $title），参数会被忽略，仍走自动解析或报错。
- 确保类构造函数形参有明确变量名，例如：
public function __construct(string $apiUrl, int $timeout = 30) { ... } - 调用时传入的数组 key 必须是
'apiUrl'和'timeout'，不能是'url'或't' - 未提供的参数仍由容器自动解析（比如类型提示的类依赖），但显式传入的值会优先覆盖
不支持嵌套对象或闭包作为 $parameters 的值
app()->make() 的第二个参数仅用于“构造函数最外层的标量或简单对象”，它不会递归解析嵌套结构，也不接受闭包来延迟计算。
- 传
['config' => ['host' => 'x']]没用：如果构造函数期待的是Config $config，那这个数组不会自动转成Config实例 - 传
['logger' => fn() => app('log')]会原样传入，不会执行，导致类型错误 - 真正需要复杂初始化时，应改用
app()->build($class)+ 手动 setConstructorParameters，或直接 new 实例
替代方案：用 app()->build() 更可控，尤其适合动态参数场景
当你要传的参数本身来自运行时计算、或涉及对象实例、或想绕过容器自动解析逻辑时，app()->build() 是更底层也更可靠的选择。
-
app()->build(MyService::class)返回一个未初始化的反射实例 - 再调用
setConstructorParameters(['apiUrl' => 'https://api.x', 'client' => $httpClient]) - 最后
resolve()触发构造 —— 此时你传什么就进什么，无自动推断干扰 - 注意：
build()不走绑定逻辑（比如 singleton 绑定），每次调用都新建实例
laravel 9+ 中 make() 第二个参数已标记为 @internal，不建议在业务代码中强依赖
查看 Laravel 源码可知，make($abstract, $parameters) 的第二个参数在 Container 类中被标注为 @internal，文档也未公开说明。它的存在主要是为框架内部（比如事件监听器解析、控制器方法注入）提供支持，而非面向开发者稳定 API。
这意味着：
- 未来版本可能删掉该参数，或语义变更
- 测试覆盖率低，边缘 case（如含默认值的可选参数）行为不稳定
- 真要解耦依赖，推荐用接口绑定 + context-aware provider，而不是硬编码参数数组
实际项目里，看到别人用 app()->make(X::class, [...])，第一反应应该是检查是否真无法通过绑定配置解决 —— 大多数时候，问题出在设计上，不在调用方式上。
