bind每次解析新建实例，singleton只创建一次并复用；前者适合无状态工具类，后者适合日志处理器等需共享状态的场景，生命周期和状态共享性由此决定。
服务容器里 bind 和 singleton 有什么区别
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 [ <required> $xxx ]] in class Yyy</required>，本质是容器找不到对应类或没配好绑定。
- 确认类文件存在且命名空间正确，
use语句没写错，特别是用了别名或相对路径时容易漏掉\ - 如果依赖的是接口，必须提前用
bind或singleton绑定实现类，例如：$this->app->bind(LoggerInterface::class, FileLogger::class) - 构造函数参数类型提示不能是匿名类、标量或数组——容器只处理类名或接口名；想传字符串配置？得用
bind配闭包，或者改用contextual binding - 在 service provider 的
register()方法里绑定，别放在boot()，否则可能因加载顺序导致解析失败
在控制器方法里怎么手动从容器取实例
多数时候靠构造函数注入就够了，但有些动态场景（比如根据请求参数决定用哪个策略类）必须运行时获取。
- 最安全的方式是通过
$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+ 后建议优先用依赖注入，而非运行时取
为什么有些类自动注入失败，但加了 @var 注解就正常了
这不是注解生效了，而是 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 绑定后对象内部有可变状态，或者在队列任务里复用了不该复用的实例，这类问题往往在线上才暴露，而且不好复现。
