必须在provider.php中绑定而非控制器new，因thinkphp6容器启动时一次性构建，provider.php是唯一自动加载的绑定入口；控制器new会绕过容器导致依赖无法注入、状态冲突且连接无法复用。
直接在 app/provider.php 里用 bind() + singleton() 绑定，别在控制器里 new 实例——否则依赖无法解耦，状态还会出问题。
为什么必须用 provider.php 而不是控制器里 new
ThinkPHP 6 的服务容器是启动时一次性构建的，provider.php 是唯一被框架自动加载并执行的绑定入口。你在控制器里 new PHPMailerService()，等于绕过容器，所有依赖（比如配置、日志、连接池）都得手动传，而且每次调用都是全新实例——PHPMailer 内部的 SMTP 连接、附件缓存等状态会冲突或泄漏。
-
app()->make(MailService::class)每次返回的必须是同一个实例，才能复用连接 - 只写
bind()不写singleton()，会导致每次make()都新建对象，违反单例语义 - 接口绑定必须声明实现类的完整命名空间，例如
app\service\PHPMailerService，不能只写类名
bind() 和 singleton() 怎么配才对
两者不是二选一，而是配合使用：bind() 声明“哪个接口对应哪个实现”，singleton() 声明“这个实现只初始化一次”。漏掉任一个都会翻车。
- 正确写法：
app()->bind(MailService::class, PHPMailerService::class)->singleton();
- 错误写法：
app()->bind(MailService::class, function () { return new PHPMailerService(); });—— 匿名函数每次执行都 new，singleton()失效 - 更安全的写法（显式控制构造）：
app()->bind(MailService::class, function () { return app()->make(PHPMailerService::class); })->singleton();，确保构造过程也走容器解析
绑定后怎么用？注意命名空间和自动注入
绑定生效后，所有地方都可以通过类型提示或 app()->make() 获取实例，但前提是类的构造函数参数能被容器自动解析。
- 控制器中直接类型提示即可：
public function send( MailService $mail ) { $mail->send(...); } - 如果
PHPMailerService构造需要Config或Log，确保这些类也已绑定或可自动实例化 - 没绑定的类（比如第三方 SDK 类）需手动注册到容器，否则类型提示会报
Entry "xxx" not found - 别在
__construct里直接app()->make()，容易形成隐式依赖，破坏可测性
最常被忽略的是：绑定语句必须放在 provider.php 的全局作用域里，不能包在函数或条件判断中；而且一旦绑定，就不能在运行时覆盖——改完要清空 runtime/container/ 缓存，否则旧绑定仍生效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
