service构造函数参数超4个是架构问题而非风格问题，需拆分逻辑层、用工厂解耦上下文依赖、确保接口逐层绑定。
Service构造函数参数超过4个就该警惕
这不是代码风格问题，而是架构信号：依赖堆叠说明职责在膨胀。ThinkPHP默认单例+容器注入，但构造函数里塞进UserRepository、OrderService、CacheInterface、LoggerInterface、EventDispatcher——光是类型提示就占半屏，后续维护和测试成本会指数级上升。
- 每个依赖都意味着一次容器解析，链路越长，启动耗时越明显；
- 一旦某个依赖含请求上下文（比如带
Request的Cache），整个Service实例在并发下可能状态错乱； - 单元测试时得 mock 一堆对象，
Mockery::mock()写到怀疑人生。
拆分逻辑层，别把Logic塞进Service
常见错误是把规则判断、多条件校验、状态机流转全扔进OrderService::createWithStockLock()里。结果这个方法既要查库存、又要验优惠券、还要触发风控拦截、最后才调用$this->stockRepo->decrease()——它已经不是Service，是业务调度中心。
- 把规则校验、组合策略、状态转换抽成独立
OrderCreateLogic类，它只接收原始数据，返回bool或ValidationResult； -
OrderService专注三件事：事务边界控制、跨库/跨服务协调、结构化数据组装； -
OrderCreateLogic通过方法参数注入所需依赖，避免构造函数污染，也方便单独测试。
用工厂模式解耦“带上下文”的依赖
当Service必须用到Request、Session或当前用户Auth::user()时，硬塞进构造函数会导致单例失效。这时候别改生命周期为瞬态——性能代价太大，而是把这部分依赖延迟到方法内构建。
- 在
app/provider.php中注册工厂闭包：'app\service\OrderServiceFactory' => function($app) { return new OrderServiceFactory($app->make(Request::class)); }； -
OrderService本身不依赖Request，构造函数只收StockRepository、OrderRepository等无状态依赖； - 需要上下文的操作（如生成订单号前缀）改由
OrderServiceFactory::makeForCurrentRequest()产出临时实例。
接口绑定没做全？依赖链会在中途断掉
你以为只绑了UserService就够了，但它构造函数里还依赖UserRepositoryInterface，而你漏掉了这条绑定——容器走到第二层就卡住，报BindingResolutionException，但错误信息根本不会告诉你缺哪一环。
- 逐层检查
UserService->__construct()里每个类型提示，确认是否都已在provider.php中显式绑定； - 运行
php -a执行var_dump(class_exists('app\repository\DbUserRepository'))，false 就别往下试了； - 改过命名空间或路径后，必须跑
php think optimize:autoload，否则class_exists()永远返回false。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
