手动调用app()或resolve()比自动注入慢，因每次调用都触发完整依赖解析链（反射→检查参数→递归解析→实例化→注入），而自动注入仅在控制器实例化时执行一次；高频手动调用会将“一次搞定”拆为N次，且易引发N+1式性能问题。
手动调用 app() 或 resolve() 为什么比自动注入慢
不是函数本身慢，而是每次调用都触发一次完整的依赖解析链：反射构造函数 → 逐层检查参数类型 → 递归解析每个依赖 → 实例化 → 注入。自动注入只在控制器实例化时做一次，而手动调用可能在循环、高频方法里反复执行，把本该“一次搞定”的事拆成 N 次做。
常见错误场景：
- 在
store()方法里写$service = app(SomeService::class)，但该服务本该通过构造函数注入 - 模板中用
@inject('logger', \Illuminate\Log\Logger::class)，却在 Blade 循环内反复调用$logger->info() - 事件监听器里手动
new SomeHandler(app(Repository::class))，绕过容器又强行拉服务
__construct 里手动 new 类直接破坏自动解析
一旦你在控制器或服务类的构造函数里写 new SomeDependency()，Laravel 容器就彻底放弃对该类的依赖管理——它不会帮你补全其他参数，也不会尝试解析剩余类型提示，直接抛 ArgumentCountError: Too few arguments。
根本原因：容器只对**由它自己创建的实例**执行自动注入。手动 new 出来的对象，$this->container 是 null，后续所有 $this->resolve() 都会报 Call to a member function resolve() on null。
正确做法：
- 删掉所有
new，改用构造函数类型提示：public function __construct(private SomeService $service) { } - 确保该类是通过路由访问或
app(SomeController::class)获取，而非new SomeController() - 如果必须动态决定实现（比如根据配置选支付网关），用接口绑定 + 构造注入，而不是运行时
new
接口绑定没生效？90% 是绑定位置或写法错了
控制器里写 SomeContract $gateway 却报 Target [App\Contracts\SomeContract] is not instantiable，说明容器根本不知道该用哪个实现类。
典型错误：
- 在
AppServiceProvider::register()外写绑定（比如直接在bootstrap/app.php里调$app->bind()） - 用字符串写法：
$this->app->bind('App\Contracts\SomeContract', 'App\Services\Alipay')—— Laravel 8+ 不支持字符串解析，必须用::class - 绑定的是具体类但没处理它的依赖：比如
AlipayGateway的构造函数要HttpClient $client，但没提前绑定HttpClient::class
正确绑定示例：
$this->app->bind(
SomeContract::class,
AlipayGateway::class
);
自动解析性能瓶颈其实不在容器，而在反射和文件 I/O
Laravel 6 的容器解析本身很快，真正拖慢的是 PHP 反射读取类文件 + 自动加载器找文件的过程。尤其在开发模式下，APP_DEBUG=true 且未缓存配置/路由时，每次请求都要重新扫描 config/ 和 routes/ 目录。
立竿见影的优化项：
- 生产环境必须跑：
php artisan config:cache、php artisan route:cache（Laravel 6 支持） - 确认
opcache.enable=1且opcache.validate_timestamps=0（FPM 下生效） - 部署时加
--optimize-autoloader --classmap-authoritative，生成扁平 classmap，跳过 PSR-4 动态查找 - 别在循环里反复调
app()；真需要条件性服务，优先用构造注入 + 策略模式或工厂类封装
复杂点在于：自动解析的“智能”背后是反射开销，而手动调用看似可控，实则容易失控。最省心的做法，是让容器管到底——从控制器到服务再到策略，全部走类型提示 + 构造注入，把 app() 留给极少数无法注入的边界场景（比如闭包回调、测试 mock）。
