Hyperf容器不执行Closure绑定的返回值，因bind()仅存储闭包而不求值；应改用singleton()注册，确保首次get()时执行闭包并缓存实例，避免注入时传入Closure导致TypeError。
Hyperf容器不执行Closure绑定的返回值
Hyperf的DI容器在解析依赖时，只对显式注册的类、接口或别名做实例化；它不会自动调用用户传入的Closure来获取实例。也就是说，当你用$container->bind(Service::class, function () { return new Service(); });注册后，容器内部存储的是这个闭包本身，而非闭包执行结果——后续get()时直接返回该闭包，而不是你期望的对象。
bind()和singleton()的行为差异必须分清
bind()只是简单映射一个名称到值（可以是类、字符串、闭包），不做任何求值；而singleton()才是设计用来注册“单例对象”的方法，它会在首次get()时执行闭包并缓存返回值。
- ✅ 正确做法：
$container->singleton(Service::class, function () { return new Service(); }); - ❌ 错误写法：
$container->bind(Service::class, function () { return new Service(); });→ 后续$container->get(Service::class)拿到的是Closure，不是Service实例 - ⚠️ 注意：
bind()适合绑定具体类名、接口实现或字符串别名，不适合延迟构造逻辑
@Inject注解无法触发Closure绑定的自动求值
即使你在dependencies.php里写了Service::class => function () { ... }，Hyperf的注解扫描和自动注入流程也不会主动执行这个闭包。因为框架在构建定义（Definition）时，只识别类、接口、已注册别名这三类可解析类型，Closure被当作“不可推导的原始值”跳过处理。
- 注入失败表现：
PHP Fatal error: Uncaught TypeError: Argument 1 passed to Controller::__construct() must be an instance of Service, instance of Closure given - 根本原因：容器没把闭包当“工厂”，而是当“值”存起来了
- 替代方案：改用
singleton()+ApplicationContext::getContainer()->get(Service::class)手动取，或直接在dependencies.php中写Service::class => Service::class让容器自动new
运行时绑定需避开注解扫描盲区
如果你必须在Bootstrap或ServiceProvider中动态决定实例构造方式，优先选singleton()而非bind()；同时注意，这类绑定必须在容器完成初始化、注解扫描之后执行（即不能早于DiFactory构建完成），否则@Inject仍会找不到定义。
- 安全时机：在
Provider的register()方法中调用singleton() - 危险操作：在
beforeStart回调里用bind()注册闭包 → 注入链已固化，无效 - 调试技巧：用
$container->has(Service::class)确认是否注册成功，再用var_dump($container->get(Service::class))看实际返回类型
