解读

在国内主流的 PHP 框架（Laravel、Hyperf、Swoft、ThinkPHP6+）中，容器都支持「自动装配（Autowiring）」与「手动绑定」两种依赖注入方式。
当同一接口或类既满足自动装配规则，又被开发者显式 bind() / singleton() 时，容器到底用哪一条？
面试官想确认：

1. 你是否通读过框架源码，知道决策顺序；
2. 能否在生产环境中预判冲突、规避不可预期注入；
3. 是否具备“可读性优先”的工程思维，而不是炫技式滥用 Autowiring。

知识点

1. Laravel 容器解析顺序（源码位置 Illuminate\Container\Container::resolve）
   a. 先看 $this->instances 里有没有已实例化的单例； b. 再看$this->bindings / $this->contextual 里有没有显式绑定；
   c. 最后才进入 reflectClass → resolveDependencies 走 Autowiring。
   因此「手动绑定 > Autowiring」是硬编码逻辑，不可被配置颠倒。

2. Hyperf 基于 Psr\Container 的 Definition 数组，优先级由 $definitions 合并顺序决定，同样「显式定义 > 反射装配」。

3. 冲突带来的副作用：
   ‑ 本地测试时忘记写 bind，Autowiring 可以跑通；上线前同事补了 bind，结果实现类被替换，导致逻辑静默变更；
   ‑ 接口存在多个实现时，Autowiring 无法决策，会抛 BindingResolutionException，必须靠手动 alias 或 contextual binding 解决。

4. 国内团队的常见规范：
   ‑ 基础设施层（Repository、RpcClient）一律手动绑定，避免“神奇注入」；
   ‑ 纯业务服务层允许 Autowiring，但要求单元测试覆盖；
   ‑ 代码审查必须检查 ServiceProvider 的 bind 列表与构造函数类型提示是否一致。

答案

“在 Laravel/Hyperf 等容器实现里，手动绑定永远优先于 Autowiring。
源码层面，容器解析时会先检索 bindings 数组，命中就直接返回；未命中才进入反射阶段。
因此冲突不会导致‘谁覆盖谁’的随机行为，而是‘显式声明胜出’。
实际项目中，我会把可能变化的多实现接口通过 ServiceProvider 显式绑定，并配合别名或上下文绑定，彻底杜绝隐式注入带来的不确定性。”

拓展思考

1. 如果项目用 PHP8 属性注入（#[Inject]），优先级如何？
   答：Hyperf 中 #[Inject] 属于编译期生成代理类，仍会被显式 bind 覆盖；Laravel 原生无此属性，引入第三方包时需看其 Resolver 顺序，通常也遵循“手动 > 属性 > 反射”。

2. 微服务场景下，接口实现类在运行时动态切换（例如灰度路由），怎样既保留 Autowiring 的便利，又保证可替换？
   答：在 ServiceProvider 的 boot() 里读取 nacos/apollo 配置，条件式 $app->bind()，把“决策”推迟到框架启动阶段；同时把可能变化的类名写入 DI 配置白名单，方便 DevOps 热更新。

3. 面试反问环节，可以向面试官提问：贵团队对 Autowiring 的使用边界如何约定？是否有静态扫描工具（如 Laravel IDE Helper、Hyperf DI Scanner）强制检测隐式依赖？体现你对工程化落地的关注。