PHP 异常链怎么保留底层 PDO 错误而不暴露敏感信息

PHP 项目里最稳妥的做法是把错误分成两条出口：服务端日志保留完整的 PDOException 和异常链，客户端只收到稳定的业务提示与 request_id。不要直接把 $e->getMessage() 放进 JSON；其中可能包含 SQLSTATE、表名、DSN、文件路径，甚至参数片段。

先分清 PDOException、Throwable 与异常链

PDO 使用异常模式时，查询失败会抛出 PDOException。PHP 的 Throwable 是可被 throw 的对象所遵循的基础接口，既覆盖 Exception，也覆盖 Error。因此最外层的 HTTP 错误边界捕获 Throwable 更完整，而数据访问层仍然可以针对 PDOException 做一次有语义的包装。

getPrevious() 返回包装异常之前的异常。它适合保存“业务语义”和“底层根因”两层信息：前台知道是“数据暂时不可用”，日志仍能追到原始 SQLSTATE 和驱动错误。

用 previous 保留底层 PDO 错误

包装时不要把原异常字符串拼到用户可见消息里。下面的仓储方法只向上层暴露稳定的异常类型，同时用命名参数把原始异常挂到 previous；日志系统稍后仍可沿链读取它。

prepare(
            'SELECT id, status, total FROM orders WHERE id = :id'
        );
        $stmt->execute(['id' => $orderId]);
        $row = $stmt->fetch(PDO::FETCH_ASSOC);
        if ($row === false) {
            throw new DomainException('订单不存在');
        }
        return $row;
    } catch (PDOException $e) {
        // 保留 PDOException 作为 previous，外层不必暴露底层文本。
        throw new RepositoryException('订单读取失败', previous: $e);
    }
}

这里的关键不是“吞掉”异常，而是换一层稳定的语义。DomainException 代表可预期的业务结果，PDOException 代表基础设施失败，两者可以在统一边界使用不同的错误码。

在统一边界做脱敏响应

把脱敏动作集中在入口，控制器、仓储和模板就不会各自决定哪些字段能返回。日志记录异常类型、链深度和 request_id；响应只保留前端真正需要的字段。

getPrevious()) {
        // 记录类型和消息供服务端排查，绝不把这份数组直接返回客户端。
        $chain[] = ['type' => $current::class, 'message' => $current->getMessage()];
    }
    error_log(json_encode([
        'request_id' => $requestId,
        'exception_chain' => $chain,
    ], JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES));
}

try {
    $order = loadOrder($pdo, (int) $_GET['id']);
    respondJson(200, ['data' => $order]);
} catch (Throwable $e) {
    $requestId = bin2hex(random_bytes(8));
    writeExceptionChain($e, $requestId);
    // 客户端只拿到可展示、可关联、不可泄露底层细节的响应。
    respondJson(500, [
        'error' => 'temporarily_unavailable',
        'message' => '服务暂时不可用，请稍后重试',
        'request_id' => $requestId,
    ]);
}

生产环境还应关闭向客户端输出详细错误的配置，并让日志访问受权限控制。脱敏不等于丢失证据：request_id 把一次用户请求和一条完整服务端日志连接起来。

检查日志、事务和异常链的常见坑

还要注意两点：第一，finally 中再次抛异常可能改变最终传播的异常，清理代码不要覆盖原始根因；第二，连接失败也可能在构造 PDO 时直接抛出 PDOException，不能只在某个查询方法周围捕获。

相关问题

为什么最外层捕获 Throwable 而不是 Exception？

因为 Throwable 同时覆盖 Error 和 Exception。统一边界需要兜住可记录的 PHP 致命错误，但业务代码仍应尽量缩小捕获范围。

可以把 PDOException 的 message 写入日志吗？

可以，但要先确认日志权限、保留周期和敏感字段策略；不要把同一条原文复制到 HTTP 响应、前端埋点或用户可见页面。

异常链太长怎么办？

记录类型、消息和链深度即可，必要时设置最大深度并保留最后一个根因。更重要的是查清哪一层包装时丢失了 previous。