thinkphp解耦需用服务容器替代硬编码：控制器通过接口依赖注入获取服务，避免new实例；bind用于无状态服务，singleton用于有状态服务；绑定须在provider.php中提前注册且控制器由框架自动实例化。
ThinkPHP 默认控制器与模型、视图之间硬编码调用，不加干预就会导致改一个字段名要翻 5 个文件——这不是开发，是考古。
为什么 new User() 是耦合的起点
很多项目里，控制器直接 new User() 或 Db::name('user')，等于把数据访问层的实现细节（表名、字段、连接方式）焊死在业务逻辑里。一旦用户表拆分成 user_base 和 user_profile，所有 new User() 都得手动改，连 IDE 都没法安全重命名。
- 它绕过了服务容器，失去统一管理生命周期的能力
- 测试时无法 mock 依赖，只能连真实数据库跑 case
- 无法按环境切换实现（比如本地用文件缓存，线上用 Redis）
bind() 和 singleton() 怎么选
ThinkPHP 的服务容器支持两种绑定方式，选错会埋下内存泄漏或状态污染的坑。
-
bind('UserInterface', 'app\common\service\UserService')：每次获取都新建实例，适合无状态、轻量服务（如短信发送器） -
singleton('UserInterface', 'app\common\service\UserService')：全局唯一实例，适合带连接池、缓存或需共享状态的服务（如 Redis 客户端封装） - 别对模型类直接 bind，模型本身应由容器自动解析其依赖（如
UserModel依赖Db），而不是手动注册
控制器里怎么写才算解耦
控制器不该知道“从哪来”，只该关心“做什么”。下面这段才是合格写法：
class UserController extends BaseController
{
protected $userService;
public function __construct(UserInterface $userService)
{
$this->userService = $userService;
}
public function register()
{
$result = $this->userService->create($this->request->param());
return json($result);
}
}
- 构造函数类型提示
UserInterface，不是具体类名，接口定义契约 - 不调用
new、不硬写app\model\User，也不写Db:: - 接口实现类在
app/common/service/UserService.php里，可随时替换成基于 Swoole 的异步实现
容易被忽略的初始化陷阱
光写接口和绑定还不够，容器要真正生效，必须确保两点：
- 控制器不能通过
new UserController()手动实例化，必须由框架路由调度——否则依赖注入根本不会触发 - 接口绑定代码必须在容器启动前注册，推荐放在
app/provider.php中，而不是在控制器里临时think\Container::getInstance()->bind(...) - 如果用了多应用模式，注意
provider.php是按应用加载的，公共服务要放对位置
最常出问题的是：开发者写了接口和实现，也绑了，但控制器仍用 new 调用——此时容器形同虚设，所有解耦努力白费。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
