Service方法必须用动词开头，聚焦业务动作如createOrder()、lockStockAndDeduct()，避免名词性命名；需体现事务边界与组合意图，禁止响应处理和字段转换，返回原始结构化数据。
Service 方法必须用动词开头，不能套用 Model 风格的 getXXX
ThinkPHP 的 Model 层习惯用 getInfo()、getList() 这类名词性命名，但 Service 层不是数据搬运工，而是业务动作执行者。一旦写成 getUserInfo()，就模糊了职责边界——这该是 Model 或 DTO 做的事。
正确做法是聚焦“做了什么”：下单、锁库存、发起退款、同步日志。这些都得是明确的动作指令。
-
createOrder()而不是getOrderInfo() -
lockStockAndDeduct()而不是checkStock() -
processRefund()而不是refundStatus() - 批量操作加复数或范围限定：
batchUpdateStatus()、cancelUnpaidOrders()
方法名要体现事务边界和组合意图
Service 方法是事务控制的基本单元。一个方法名如果看不出它是否“原子”，就容易在调用时漏掉事务包裹，或者把本该一次完成的多步操作拆到多个 Service 调用里，导致状态不一致。
比如「下单」这件事涉及查库存、扣减、写订单、发消息，不能拆成四个方法分别调；而应封装为一个动词+宾语+修饰结构的方法名，让调用方一眼明白这个方法干了什么、是否可重入、是否需事务兜底。
立即学习“PHP免费学习笔记（深入）”；
- 推荐：
createOrderWithStockLock()、fulfillAfterPaymentVerification() - 避免：
checkStock()+saveOrder()+sendMessage()（三者分离，事务难统一） - 如果方法内部有分支逻辑（如根据支付方式走不同流程），名字可带条件提示：
createOrderForAlipay()，但更推荐抽成策略模式，主方法仍保持语义清晰
禁止在 Service 方法里做响应处理或字段转换
常见错误是把 formatUserResponse()、buildApiResult() 这类方法塞进 Service，结果导致 Service 既管业务又管表现，后续换小程序/H5/后台管理就要改 Service，违反单一职责。
Service 只返回原始、完整、结构化的数据（数组或 DTO 对象），字段过滤、时间格式化、状态码包装全部交给 Controller 或 Logic 层。
- ✅ 正确返回：
return ['order_id' => $id, 'status' => 1, 'created_at' => $time] - ❌ 错误写法：
return ['code' => 200, 'msg' => 'success', 'data' => [...]]（这是响应组装，不是业务结果） - 别用
toApiArray()、toArrayWithExtra()这类方法名——Service 不负责“对外怎么展”
复杂业务建议前缀区分场景，但别堆砌形容词
当同一业务实体需要多种行为路径时（比如用户注册，有手机号注册、微信授权注册、邀请码注册），靠参数区分容易让方法膨胀、校验逻辑混杂。这时可用业务前缀划清语义，但必须克制。
- 可接受：
registerByMobile()、registerByWechat()、registerByInviteCode() - 危险信号：
registerByMobileWithSmsVerifyAndInviteCheckAndSendWelcomeMessage()（名字过长 = 职责过重） - 如果后缀已超 4 个词，说明该拆：把短信校验、邀请码检查、欢迎消息分别抽成独立 Service 方法，主方法只做编排
最常被忽略的一点：方法名看似小事，但它直接暴露 Service 是否真正承担了“业务编排”角色。如果翻看你的 app/service 目录，发现一半方法名以 get 开头、三分之一含 format/to/api 字样，那大概率 Service 层只是 Model 的壳子，还没开始承接真正的业务复杂度。
