具体情况具体分析：

• Controller 一般的职责是：校验用户输入（query，body） + 处理业务逻辑 + 渲染模板并响应。
• 其中，处理业务逻辑 这一步，一些共用的逻辑，是可以抽象为 Service 的。
• 但不是一定要抽取，如果只需要直接调用 BaaS 服务，如调用 oss 之类的，那完全可以直接在 Controller 里面做完，因为 BaaS 就是一个简单的远程 Service 了。
• 抽离 Service 的一个好处是，方便单测，因为 Controller 的测试是跟 HTTP 绑定的，你需要用 supertest 之类的测试。
• 如果你的一段业务逻辑是多发的，可以是 HTTP 触发，也可以是定时任务触发的，这时候你放在 Controller 里面自然不好。

代码也不是一成不变的，只要把单测都写了，跟着业务变化，按需重构就好了。

这个我是严格准守的，可以用现在比较流行的管道思想来解释 controller 负责管道的调用，不负责具体logic service 负责比较完整的原子性事务 比如一个注册功能 1.发送邮件 2.存储数据 这两个步骤分别可以写入service，然后controller来调用。 如果形成良好的习惯，到项目后期会有大量可复用的service