Laravel怎么使用服务容器_Laravel怎么实现依赖注入【核心】-Laravel-PHP中文网

bind每次解析新建实例，singleton只创建一次并复用；前者适合无状态工具类，后者适合日志处理器等需共享状态的场景，生命周期和状态共享性由此决定。

laravel怎么使用服务容器_laravel怎么实现依赖注入【核心】

bind 每次解析都新建实例，singleton 只创建一次、后续复用——这直接决定对象生命周期和状态是否共享。

如果你注册的是一个带数据库连接的 UserService，用 bind 每次都会 new 一个新对象，连接可能重复打开；用 singleton 就只连一次，但要注意它内部状态（比如缓存属性）会被所有调用者共用
bind 适合无状态工具类，比如 StrHelper；singleton 更适合真正需要单例语义的场景，如日志处理器、配置管理器
Laravel 的 App::make() 默认走绑定类型，你没显式指定时，bind 是默认行为；而 app('xxx') 调用效果一样，但底层依赖绑定定义

常见现象是报错 Target class [xxx] does not exist 或 Unresolvable dependency resolving [Parameter #0 [ $xxx ]] in class Yyy，本质是容器找不到对应类或没配好绑定。

确认类文件存在且命名空间正确，use 语句没写错，特别是用了别名或相对路径时容易漏掉 \
如果依赖的是接口，必须提前用 bind 或 singleton 绑定实现类，例如：$this->app->bind(LoggerInterface::class, FileLogger::class)
构造函数参数类型提示不能是匿名类、标量或数组——容器只处理类名或接口名；想传字符串配置？得用 bind 配闭包，或者改用 contextual binding
在 service provider 的 register() 方法里绑定，别放在 boot()，否则可能因加载顺序导致解析失败

多数时候靠构造函数注入就够了，但有些动态场景（比如根据请求参数决定用哪个策略类）必须运行时获取。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

最安全的方式是通过 $this->app 或 app() 辅助函数，例如：app(PaymentStrategy::class)->process($order)
避免直接 new 实例再塞进容器，比如 $this->app->instance(...)，除非你明确要覆盖已有绑定——它会静默替换，调试时很难发现哪段代码偷偷改了绑定
如果要用上下文绑定（比如「当注入到 OrderController 时用 AlipayStrategy，注入到 RefundController 时用 WechatStrategy」），得用 when()->needs()->give() 链式调用，不是简单 bind
注意：在模型的 boot() 或 accessor 中调用 app() 可能触发容器未完全启动的错误，Laravel 5.8+ 后建议优先用依赖注入，而非运行时取

这不是注解生效了，而是 IDE 或 PHPStan 等静态分析工具“以为”你写了类型，实际 Laravel 容器根本不看 docblock。真正在起作用的是自动加载 + 类名推导规则。

Laravel 在解析构造函数参数时，只认 type-hint（也就是冒号后面的真实类名），@var 或 @param 注释完全不参与解析
看起来“加了注解就好了”，大概率是因为你顺手把类引入写对了，或者文件命名/命名空间终于匹配上了自动加载规则
另一个干扰项：PHP 8 的构造函数属性提升（public function __construct(private UserService $service)）会让 type-hint 更紧凑，但它和注解无关，容器照样只读这个 UserService 类名
验证方式很简单：删掉所有 docblock，只留正确 use 和 type-hint，依然能注入成功——那说明本来就好使；如果不行，问题一定出在类路径或绑定上，不是注解的事

依赖注入本身不复杂，难的是绑定时机、接口与实现的映射关系、以及各种“看似能跑通实则埋雷”的隐式行为。尤其是 singleton 绑定后对象内部有可变状态，或者在队列任务里复用了不该复用的实例，这类问题往往在线上才暴露，而且不好复现。