在 symfony 4 中，应将数据库查询和业务逻辑封装进职责单一的自定义服务，通过依赖注入调用 repository 执行查询，服务仅处理结果加工与业务动作，严禁手动 new 实例或在服务中渲染响应。
在 Symfony 4 中，把数据库查询和业务逻辑封装进自定义服务，是保持控制器轻量、提升复用性与可测试性的标准做法。关键不是“能不能查”，而是“谁来查、怎么查、查完做什么”——服务层就是这个角色。
服务类要专注单一职责
一个服务类对应一个明确的业务能力，比如 UserManagementService 负责用户注册、状态变更、批量禁用；OrderStatisticsService 负责计算销量、统计时段订单。不要让一个服务既查用户又发邮件还生成报表。
- 构造函数里只注入真正需要的依赖，如
EntityManagerInterface、其他服务、配置参数 - 方法名体现意图，例如
findActiveUsersByRegion(string $region)比getData($a, $b)更清晰 - 避免在服务中直接调用
$this->render()或返回Response对象——那是控制器的事
查询逻辑优先走 Repository，别绕过它
即使你封装了服务，也别在服务里手写 createQuery() 或拼 DQL 字符串。正确的链路是：
- 服务调用自定义 Repository 方法（如
$this->productRepository->findByStatusAndPriceRange(...)） - Repository 内部用
createQueryBuilder()组装条件，返回实体或投影数组 - 服务对结果做进一步加工：格式转换、权限过滤、组装 DTO、触发后续动作（如记录日志、分发事件）
这样分层后，Repository 只管“怎么查”，服务只管“查完干什么”，单元测试时可以轻松 mock Repository 返回任意数据。
注入方式要规范，别 new 实例
服务必须通过容器注入，不能手动 new。在 config/services.yaml 中确认已启用自动注册：
yml
services:
# 默认开启，确保你的服务类在 App\Service\ 下即可被扫描
App\Service\:
resource: '../src/Service/*'
tags: ['controller.service_arguments']
然后在控制器或另一个服务中直接声明类型提示即可使用：
php
public function listProducts(ProductStatisticsService $statsService): Response
{
$data = $statsService->getTopSellingThisMonth();
return $this->json($data);
}
复杂逻辑别堆在服务方法里
如果某个查询涉及多步判断、外部 API 调用、事务控制或异步处理，就该拆出去：
- 事务边界交给控制器或专用命令类控制，服务内部默认不开启事务
- 调用第三方接口的逻辑单独抽成
ApiClient服务，由业务服务组合调用 - 需要异步执行的动作（如发邮件、生成报表）通过事件分发器触发监听器，服务只负责 dispatch 事件
比如用户下单成功后更新库存并通知物流，服务里只需 $eventDispatcher->dispatch(new OrderPlacedEvent($order))，后续动作由监听器完成。
