symfony 4 中自定义业务服务的关键是职责清晰、可测、可复用、易替换：服务只做一件事，不耦合控制器、不直连请求/响应、不硬编码配置；命名应体现领域行为（如userregistrationservice），目录按service/domain/infrastructure分层；依赖接口而非具体实现，方法需明确输入输出，配置须通过注入而非硬编码。
在 Symfony 4 中，自定义业务服务不是“写个类再注册就行”，关键在于职责清晰、可测、可复用、易替换。核心原则是：服务只做一件事，不耦合控制器、不直连请求/响应、不硬编码配置值。
服务命名与位置规范
服务类名应体现领域行为，而非技术实现。例如：
UserRegistrationService ✅（表达业务意图）
UserRepository ✅（明确数据访问职责）
UserHelper ❌（模糊、易泛滥）
UserControllerService ❌（混入控制器语义）
推荐目录结构：
-
src/Service/ —— 主业务逻辑（如
OrderProcessingService） -
src/Domain/ —— 领域模型与接口（如
PaymentGatewayInterface） -
src/Infrastructure/ —— 具体实现（如
StripePaymentGateway）
依赖注入与接口抽象
避免在服务构造函数中依赖具体类，优先面向接口编程：
- 定义
NotificationSenderInterface，而非直接注入MailgunClient - 在
services.yaml中绑定实现：App\Domain\NotificationSenderInterface: '@App\Infrastructure\MailgunNotificationSender' - 单元测试时可轻松传入模拟对象（Mock），无需启动容器
方法设计与副作用控制
业务服务方法应具备明确输入输出，无隐藏状态或意外 I/O：
- ✅ 推荐：
public function calculateDiscount(Order $order): float（纯计算，无数据库/网络调用） - ✅ 推荐：
public function placeOrder(OrderData $data): Order（有副作用，但契约清晰） - ❌ 避免：
public function process()（含义不清，参数隐式来自 $this->request 或全局状态） - 避免在服务中调用
$this->redirectToRoute()、$this->json()等响应相关方法
配置与环境隔离
服务内部不应硬写 API 密钥、超时时间等值。正确方式：
- 通过构造函数或 setter 注入配置参数（类型化，如
int $timeoutSeconds） - 在
services.yaml中使用%env(…)%或%parameter_name%绑定 - 敏感配置统一走
.env+config/packages/*.yaml分层管理
不复杂但容易忽略
