service层应抛出语义明确的自定义异常（如inventoryexception），继承runtimeexception并携带code和msg；controller交由全局异常处理器按类型分层响应，禁止透传底层异常或空catch。
Service 层不该直接 throw new Exception
Service 层是业务逻辑中枢，不是错误出口。直接 throw new \Exception() 会把底层异常细节（比如 SQL 错误、文件路径）一路透传到控制器甚至前端，破坏分层边界，也容易泄露敏感信息。
正确做法是定义业务语义明确的自定义异常类，例如 OrderException、InventoryException，统一继承 think\Exception 或 RuntimeException，并在构造时固定 $code 和 $msg。
- 避免用
throw new \Exception('库存不足')这类无结构字符串 - 推荐写法：
throw new InventoryException('库存不足', 4001) - 所有业务异常都应有唯一数字码，方便前端识别和埋点统计
Service 抛出异常后，Controller 怎么接住
Controller 不该用通用 catch (\Exception $e) 捕获一切，而应按类型分层处理：
- 捕获业务异常（如
OrderException）：返回用户友好的提示，状态码用400或422，内容用json(['code' => $e->getCode(), 'msg' => $e->getMessage()]) - 捕获系统异常（如
PDOException、RedisException）：记录日志后转为泛用错误，不暴露细节，返回500或降级响应 - 不建议在 Controller 里
try/catch每个 Service 调用——太碎；推荐统一由全局异常处理器接管
全局异常处理器怎么区分 Service 异常和框架异常
ThinkPHP 的 render() 方法接收的是原始 Throwable，关键判断依据是类名和是否含业务语义：
- 检查
$e instanceof \app\exception\OrderException等具体类，走定制 JSON 响应 - 检查
$e instanceof \think\exception\ValidateException，返回422+ 验证字段错误 - 对
$e instanceof \PDOException等底层异常，只记日志、返回500，绝不吐 trace - 注意：不要依赖
$e->getPrevious()判断来源——Service 层抛出时可能已丢失上下文
Service 层内部要不要 try/catch 数据库操作
要，但目的不是“吞掉异常”，而是做两件事：转化 + 补偿。
- 把 PDO 异常转化为业务异常：
catch (\PDOException $e) { throw new DbOperationException('下单失败，请重试', 5003); } - 需要补偿时（如扣库存成功但创建订单失败），在
catch里调用逆向操作（回滚库存），再重新抛出业务异常 - 不要空
catch，也不要只Log::error()就完事——Service 必须明确告诉上层“这事没成，为什么没成”
render() 返回值必须是 Response 实例，否则 ThinkPHP 会二次包装成 HTML 页面——哪怕你 Service 抛的是 JSON 异常，最后也可能被套上框架 footer。这点在 API 场景下极易踩坑。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
