ThinkPHP分层开发实践：Service层到底该放哪些业务逻辑？

最近重构老项目时，一直在纠结Service层的边界问题。Controller只做参数校验和返回响应，Model只处理数据交互，那业务逻辑到底该往哪放？

我的经验是：Service层应该包含以下三类逻辑： 1. 需要组合多个Model操作的业务流（比如用户注册要同时写用户表、发欢迎消息） 2. 涉及第三方服务的调用（支付接口、短信验证码） 3. 需要复用的核心计算逻辑（优惠券核销规则）

特别注意不要变成"万能垃圾筐"：视图组装、权限校验这些明显属于Controller；而数据字段过滤、关联查询这种活就该Model自己扛。上周就因为把权限校验写进了Service层，导致API和后台管理两边鉴权逻辑打架。

推荐在Service层使用门面模式，比如UserService::register()这种静态调用比直接new更清爽。但要注意避免循环依赖——我就遇到过OrderService调PaymentService，结果PaymentService又回调OrderService的死锁情况。

你们项目中Service层还遇到过哪些典型场景？欢迎交流踩坑经验~