Service类不能直接作插件入口，必须通过ServiceProvider在register()中显式绑定进容器，如$this->app->singleton(PaymentService::class, fn() => new PaymentService())，并确保命名空间与目录结构严格匹配。
Service 类不能直接当插件入口，必须靠服务提供者注册
ThinkPHP 的 Service 类本身只是普通业务类，没有生命周期钩子、不参与框架启动流程，也不能被自动发现或启用/禁用。想让它成为插件的一部分，必须通过 ServiceProvider 绑定进容器，并配合插件系统（如 think-addons）的加载机制。
常见错误现象：app/service/PaymentService.php 写好了，也在插件目录里，但控制器里 app()->make(PaymentService::class) 报错找不到——根本原因不是路径问题，而是这个类压根没被容器知道。
- 插件中的
Service必须在插件自己的ServiceProvider的register()方法里显式绑定，例如：$this->app->singleton(PaymentService::class, function () { return new PaymentService(); }); - 该
ServiceProvider类需放在插件目录内（如addons/demo/src/Provider/PaymentServiceProvider.php），且命名空间要与目录结构严格匹配 - 若用
think-addons，插件的Plugin.php中需在install()里触发服务发现（比如执行php think service:discover），或手动把服务提供者写入config/addons.php的providers配置项
插件里的 Service 如何安全注入请求上下文
插件中常需访问当前请求、用户登录态或配置，但 Service 默认是单例，直接在构造函数里依赖 Request 或 Session 会导致并发下状态污染。
正确做法不是让 Service 自己去 app()->make(Request::class)，而是由服务提供者控制实例化时机和作用域：
立即学习“PHP免费学习笔记（深入）”；
- 在
ServiceProvider::register()中使用闭包绑定，每次获取都新建实例：$this->app->bind(PaymentService::class, function ($app) { return new PaymentService($app->make(Request::class)); }); - 若需复用部分依赖（如数据库连接），可只对请求相关对象做“每次请求新建”，其他用
$app->get(...)获取单例 - 避免在
Service构造函数中调用app()或input()等全局函数——它们可能在命令行或定时任务中不可用，破坏可测试性
插件启用时 Service 才加载，卸载时如何清理
ThinkPHP 插件系统本身不接管 Service 的生命周期，uninstall() 方法里删文件、清缓存都没法让已绑定进容器的 Service 自动失效。
这意味着：一旦插件启用并完成服务绑定，即使后续禁用或卸载，app()->make() 仍能取到该 Service 实例，除非你主动干预容器。
- 不要在
uninstall()里尝试调用$this->app->forgetInstance(...)——插件卸载时容器可能已进入销毁阶段，操作无效甚至报错 - 真正安全的做法是：把插件 Service 的绑定逻辑放在
boot()阶段而非register()，并在boot()开头加判断：if (!addon_is_enabled('demo')) return; - 更彻底的解耦方式是让插件 Service 不直接暴露类名，而是统一走接口+条件绑定，例如：
$this->app->when(OrderServiceInterface::class)->needs('OrderService')->give(function () { ... });，再配合插件开关动态切换实现
为什么不能把 Service 直接写在 addons/demo/service/ 下就完事
因为 ThinkPHP 不会自动扫描 addons/ 目录下的 PSR-4 命名空间，composer dump-autoload 默认也不处理该路径。硬建目录只会导致 Class not found。
实操上必须二选一：
- 在插件自己的
composer.json中声明 autoload（仅适用于独立发布为 Composer 包的插件）："autoload": {"psr-4": {"addons\demo\": "src/"}}，然后运行composer dump-autoload（注意：主项目 composer 不会自动加载插件的 autoload） - 更常用的是在插件
ServiceProvider的register()中用include_once或require_once显式加载关键 Service 文件，绕过自动加载限制（适合轻量、目录即插件的场景） - 千万别把插件 Service 放进主项目的
app/service/—— 这等于把插件逻辑打进核心，失去热插拔意义，升级或卸载时还得手动删代码
最易被忽略的一点：插件 Service 的类名和命名空间必须和它被调用的位置完全一致；哪怕只是大小写差一个字母，在 Windows 下可能暂时正常，但在 Linux 生产环境必报错，且 IDE 很难提示。
