ThinkPHP 8配置二级域名与依赖注入：容器绑定与接口实现【技巧】

在ThinkPHP 8下做二级域名部署，不少开发者会遇到一个共同的困惑：域名路由和依赖注入似乎各自为政。说到底，这不是两个功能的简单叠加，而是要确保“域名把请求送到了哪里，容器就在哪里提供正确的服务”。

否则，子应用里明明写了UserService $service这种类型提示，结果却静默失效，报错时完全找不到根源。

先说几个核心判断：域名到应用的硬映射没完成，后续所有依赖注入基本是白忙活；子应用有自己的容器上下文，主应用里的绑定默认不被继承；类型提示不是魔法，必须显式告诉容器该把接口解析成哪个实现类。

二级域名必须先绑定到应用，再谈容器注入

这个顺序不能乱。域名到应用的映射是“地基”，地基没打稳，后面的容器注入就是空中楼阁。关键的三步缺一不可：

• 确认已经启用多应用模式。项目结构里要能看到app/admin/、app/api/这样的独立目录，并且已经执行过php think build admin这类命令。
• 在config/app.php中开启域名部署，设置'url_domain_deploy' => true。注意一下，这里的配置项名称不是APP_SUB_DOMAIN_DEPLOY，别搞混了。
• 最后一步，在同一个配置文件的domain_bind数组里写明绑定关系。比如['admin.example.com' => 'admin', 'api.example.com' => 'api']，这就是最直接的硬绑定。

这里要特别说明一点：光靠Route::domain()是不够的。它只有在domain_bind生效之后才会参与路由分发，否则控制器还是会跑去app/controller/目录下查找，结果自然是404。

子应用容器不共享主应用绑定，必须单独注册

如果你以为在app/provider.php里用app()->bind()绑定了接口，所有子应用就能自动享用，那恐怕要失望了。TP8把每个应用实例和容器彻底解耦了——主应用调用app()返回的是主容器，子应用自己有独立的App实例，不会继承主容器的绑定信息。

正确的做法是在子应用自己的服务提供者中完成绑定。比如在app/admin/provider.php里写：$this->app->bind(UserRepositoryInterface::class, AdminUserRepository::class)。更通用的方式则是直接操作全局容器单例，用Container::getInstance()->bind(...)来绕过应用上下文的限制。

还有个容易踩的坑：别在common.php或者全局配置里做绑定。因为那种地方的应用上下文不确定，绑定结果很可能被覆盖，或者干脆被忽略。

接口绑定必须显式声明，类型提示不会自动匹配实现

控制器方法里写了public function index(UserService $service)，结果报Class not found？这大概是90%的开发者都会遇到的状况。原因很简单：容器压根不知道UserService对应哪个类文件，也没有任何绑定信息可供查找。

处理这个问题，要分几步走：首先确保类文件确实存在，并且命名空间路径严格一致。比如app/service/UserService.php文件里必须声明namespace app\service;。然后运行php think optimize:autoload刷新自动加载，最后用class_exists('app\service\UserService')验证一下，返回true才说明加载没问题。

绑定方式选一种就可以：要么在app/admin/provider.php的数组里加一项，写清楚接口和实现类的对应关系；要么在服务提供者的register()方法中调用$this->app->bind(UserService::class, AdminUserService::class)。如果用的是接口模式，绑定必须写接口的全限定名，像bind('UserRepositoryInterface', ...)这种字符串写法是无效的。

一个常见的真实教训是：写完绑定之后记得验证一下。很多问题的根源，其实就是配置文件里漏了一个斜杠或者命名空间写错了。

单例资源必须用 singleton() + make() 配对管理

二级域名下多个子应用共用数据库连接池？这个想法听起来不错，但实际执行起来会遇到状态污染的问题。正确做法是让每个子应用独立管理自己的连接资源。

操作上要在子应用的provider.php或服务提供者中这样绑定：$this->app->singleton('redis', function ($app) { $r = new Redis(); $r->connect('127.0.0.1', 6379); return $r; });。获取资源的时候则必须用$this->app->make('redis')，不能图省事用get()——后者只认instance()注册的对象。

验证是否真正实现复用也很简单：执行$this->app->make('redis')->set('test', 'ok')，然后再执行$this->app->make('redis')->get('test')，如果返回'ok'，说明确实复用了同一个实例。

如果这里用了bind()而不是singleton()，那每次请求都会新建一个Redis实例，连接数会瞬间暴涨，服务器的压力可想而知。这不是危言耸听，线上环境确实出现过这样的问题。