绝大多数情况下异常应往外 throw 而非类内静默 catch；仅在可自治恢复、非关键路径降级或构造函数副作用等极少数场景才允许 catch 吞掉，且必须记录；throw 时应选语义精准的内置或自定义异常类，避免裸抛 Exception。
异常该在类内部 try-catch 还是直接 throw？
绝大多数情况下，异常应该往外抛，而不是在类内部静默 try-catch 吞掉。封装类不是错误兜底层，而是职责边界清晰的组件——它只负责暴露明确契约，不替调用方做决策。
常见反模式：在数据库操作方法里 catch 住 PDOException，打个日志就返回 false 或空数组。结果调用方完全不知道发生了连接失败、SQL语法错还是主键冲突，只能靠猜。
- 类内
catch仅适用于：能**完全自治恢复**的场景（比如重试一次网络请求、fallback 到本地缓存） - 需要调用方感知并差异化处理的情况（如“用户不存在”要跳注册页，“库存不足”要提示加购失败），必须
throw - 底层扩展异常（如
PDOException、RedisException）建议包装成语义更清晰的自定义异常再抛出，避免暴露实现细节
什么时候必须在类里 catch 并吞掉异常？
几乎没有“必须”的情况。但有极少数可接受的例外：
- 异步/后台任务中，防止单条失败导致整个队列中断（此时应记录完整上下文，而非丢弃）
- 非关键路径的日志上报失败，不影响主流程（例如埋点接口超时，可降级为内存暂存）
- 构造函数里无法避免的初始化副作用（如自动创建目录），且失败不影响对象基本可用性
注意：catch 后不做任何记录或通知，等同于制造黑洞。哪怕只是 error_log($e)，也比空 catch 强。
立即学习“PHP免费学习笔记（深入）”；
throw 新异常时怎么选继承类？
别一股脑都用 Exception。PHP 的异常继承体系是设计意图的显式表达：
- 逻辑校验失败 →
InvalidArgumentException（参数非法）、DomainException（业务规则违反） - 外部依赖故障 →
RuntimeException（网络、DB、文件IO失败），或进一步细分如ConnectionException - 严重不可恢复错误 →
Error子类（如TypeError）一般不手动 throw，由引擎触发；主动抛出应优先考虑LogicError或BadMethodCallException
自定义异常类只需继承对应基类，无需重写方法。重点是让 catch 方能通过类型快速识别问题域。
finally 里的资源清理要不要 try-catch？
要。尤其是涉及 fclose()、mysqli_close()、curl_close() 等可能触发警告的操作。
示例：
try {
$fp = fopen('/tmp/data', 'w');
fwrite($fp, $data);
} catch (Exception $e) {
throw new FileWriteException('写入失败', 0, $e);
} finally {
if (isset($fp) && is_resource($fp)) {
// fclose 可能因文件系统错误触发 warning，干扰原始异常
@fclose($fp); // 抑制 warning，或用 try/catch 包一层
}
}
真正容易被忽略的是：当原始异常和 finally 中的异常同时存在时，PHP 7+ 会把后者作为前者的 getPrevious()，但很多日志工具默认不展开嵌套。务必检查你的监控系统是否能透出链式异常。
