pdo 默认不抛出异常，需显式启用异常模式；真正的错误处理应覆盖整个业务流程（而非仅连接），使用 try-catch 捕获 throwable，并配合预处理语句防止 sql 注入。
pdo 默认不抛出异常，需显式启用异常模式；真正的错误处理应覆盖整个业务流程（而非仅连接），使用 try-catch 捕获 throwable，并配合预处理语句防止 sql 注入。
在从 MySQL 或 MySQLi 迁移到 PDO 时，开发者常陷入一个典型误区：试图沿用旧式 if (!$connection) 的条件判断来处理错误。但 PDO 的设计哲学根本不同——它默认静默失败，连接成功后返回一个有效的 PDO 实例（即使后续查询出错，该对象本身仍为真值），因此 if (!$database_connection) 永远不会触发，导致错误被忽略。
✅ 正确做法：启用 PDO 异常模式 + 全局异常捕获
PDO 提供了三种错误处理模式，必须显式设置为 PDO::ERRMODE_EXCEPTION，才能让连接失败、查询错误、绑定失败等全部转化为可捕获的异常：
try {
$dsn = "mysql:host=$db_host;dbname=$db_name;charset=utf8mb4";
$options = [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // 关键！启用异常
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
PDO::ATTR_EMULATE_PREPARES => false, // 禁用模拟预处理，确保真实参数绑定
];
$pdo = new PDO($dsn, $db_username, $db_password, $options);
// 执行安全的预处理语句（使用 ? 占位符，杜绝 SQL 注入）
$sql = "INSERT INTO users (name, email) VALUES (?, ?)";
$stmt = $pdo->prepare($sql);
$stmt->execute([$name, $email]);
// 后续业务逻辑（如发送邮件、记录日志等）
sendWelcomeEmail($email);
} catch (PDOException $e) {
// 专门处理数据库相关异常（如连接拒绝、表不存在、主键冲突等）
error_log("Database error: " . $e->getMessage() . " in " . $e->getFile() . ":" . $e->getLine());
die("提交失败，请稍后重试。");
} catch (Throwable $e) {
// 捕获所有其他错误（文件加载失败、函数未定义、内存溢出等）
error_log("Fatal error: " . $e->getMessage());
die("系统繁忙，请联系管理员。");
}⚠️ 重要注意事项
-
不要只包裹连接或只包裹查询：错误可能发生在配置加载、数据验证、邮件发送等任意环节。
try块应覆盖整个业务流程（从初始化到最终响应）。 -
严禁拼接 SQL 字符串：原问题中
$sql若含用户输入且未参数化，将导致严重 SQL 注入漏洞。务必始终使用?或命名占位符（:name）。 -
避免在生产环境直接
echo $e->getMessage()：会泄露敏感信息（如数据库结构、路径）。应记录到日志，并向用户展示友好提示。 - 慎用邮件告警：高频错误（如恶意表单提交）可能引发邮件风暴。推荐集成 Sentry、Loggly 等专业监控工具，实现去重、聚合与告警分级。
-
区分错误类型：
PDOException专用于数据库操作异常；Throwable是 PHP 7+ 中所有可抛出对象的基类，确保无遗漏。
✅ 最佳实践总结
-
连接即设异常模式：在
new PDO()时通过$options强制开启PDO::ERRMODE_EXCEPTION； -
统一异常边界：
try块包裹完整业务逻辑，而非碎片化检查； -
预处理语句全覆盖：所有用户输入必须通过
?绑定，禁用字符串拼接； - 分层错误响应：开发环境可显示详细错误，生产环境只记录日志+返回通用提示；
-
监控替代人工告警：用 Sentry 等工具替代
mail()，提升运维可靠性。
PDO 的强大在于其一致性与安全性，而错误处理的核心不是“如何检测连接失败”，而是“如何保障整个业务流程的健壮性”。启用异常模式并拥抱 try/catch，才是现代 PHP 数据库编程的正确起点。
