App::make 返回 null 或报错主因是类未注册、命名错误或依赖无法解析；需检查自动加载、显式绑定、避免静态调用及滥用，优先方法注入与接口绑定。
App::make 为什么有时返回 null 或报错
直接调用 App::make('SomeService') 失败，多数是因为类没被容器注册过，或者类名拼写/命名空间不对。ThinkPHP 的容器默认只自动绑定少量核心类（如 Request、Response），其他类必须显式绑定或通过接口+实现自动解析。
- 检查类是否已定义且能被自动加载 —— 运行
php think optimize:autoload确保 Composer 自动加载生效 - 若类有构造函数参数，容器无法自动推断依赖时会抛出
ReflectionException，此时需手动绑定：App::bind('SomeService', function () { return new SomeService(new DepA(), new DepB()); }); - 别传字符串别名但没绑定 ——
App::make('cache')可以，因为框架预设了别名；但App::make('user_service')会失败，除非你提前App::bind('user_service', UserService::class)
构造函数注入在控制器里不生效的常见原因
你以为在控制器构造函数里写 public function __construct(SomeService $service) 就能自动注入？不行。ThinkPHP 默认控制器不是由容器创建的，而是手动 new 出来的，绕过了容器解析流程。
- 必须把控制器也注册进容器，并启用「容器接管控制器实例化」：在
app/provider.php中添加app\controller\Index::class到providers数组 - 更稳妥的做法是改用「方法注入」：在具体 Action 方法参数中声明依赖，例如
public function index(SomeService $service) { ... }—— 这个由框架路由层自动处理，无需额外配置 - 如果坚持用构造函数注入，记得控制器类不能有除依赖外的其他必需参数，否则容器无法实例化
接口绑定与具体类之间的性能和维护差异
用 App::bind(UserRepositoryInterface::class, MysqlUserRepository::class) 而不是直接 bind 具体类，不只是为了“看起来高级”，它直接影响可测试性和切换成本。
- 测试时可轻松替换为
MockUserRepository，只要实现同一接口，App::make(UserRepositoryInterface::class)返回的就是 mock 实例 - 绑定接口后，所有通过该接口获取的实例共享同一生命周期策略（比如单例）；而直接 bind 具体类，容易出现多个地方重复 bind，导致行为不一致
- 注意：ThinkPHP 默认每次
make都返回新实例，如需单例，得显式调用App::singleton()，且 singleton 绑定优先级高于 bind
什么时候不该用 App::make，而该用依赖属性注入
在非容器管理的类（比如模型、验证器、普通工具类）里硬写 App::make() 是反模式。它把依赖关系从构造函数移到了方法内部，破坏了可测性，也隐藏了真实依赖。
立即学习“PHP免费学习笔记（深入）”；
- 模型中需要日志服务？不要在
save()里调App::make('log')，而是通过构造函数或 setter 注入，或让父类Model提供受控的访问方式 - 验证器中要用业务逻辑类？同理，避免
App::make()，应由调用方（如控制器）把依赖传进来，或使用验证器的scene+ 闭包扩展机制间接解耦 - 最典型的坑：在静态方法里调
App::make()—— 看似方便，实则让单元测试完全无法 mock，而且掩盖了该方法本就不该承担服务协调职责的事实
App::make 或加个构造函数参数，而是判断哪个类该由容器管、哪个该明确传递、哪个压根不该持有这个依赖。边界模糊时，先看它是否跨域（比如模型去碰缓存配置），再看它是否在运行期才决定用谁（这时接口绑定才有意义）。 
