将旧SQL网站迁移至PHP7+PDO时遇SQL语法错误，求排查方案

看起来你在把旧SQL系统迁移到PHP7+PDO的过程中，遇到了让人头疼的语法错误，但当前的异常日志信息太简略，没法快速定位问题根源。别担心，我们可以通过改进日志记录和调用栈追踪来解决这个问题，完全不用给每条查询都套上try/catch。

一、核心问题：日志缺少关键调试上下文 #

你现在看到的错误只告诉你SQL语法有问题，但没显示原始执行的SQL语句和绑定的参数——这才是排查错误的核心信息。比如第一个错误里的near 'username'，如果能看到完整的SQL，你立刻就能发现是少写了条件（比如WHERE username = ?写成了WHERE 'username'）还是参数绑定出了问题。

二、改进DB类，记录SQL和绑定参数 #

我们可以修改DB::run()方法，在捕获PDO异常时，把原始SQL和绑定的参数附加到错误信息里，这样日志里就有足够的调试细节了：

public static function run($sql, $args = []) {
    try {
        if (!$args) {
            return self::instance()->query($sql);
        }
        $stmt = self::instance()->prepare($sql);
        $stmt->execute($args);
        return $stmt;
    } catch (PDOException $e) {
        // 拼接SQL和参数信息，仅用于调试日志，不要暴露给前端用户
        $debugInfo = "\n执行的SQL: {$sql}\n绑定的参数: " . print_r($args, true);
        // 重新抛出异常，保留原始异常的调用栈信息
        throw new Exception($e->getMessage() . $debugInfo, (int)$e->getCode(), $e);
    }
}

修改后，你的错误日志里会包含完整的SQL语句和参数列表，比如第一个错误就能直接看到到底是哪段SQL里的username部分写错了。

三、添加调用栈追踪，定位触发查询的代码 #

如果想知道是哪个页面的哪一行代码调用了这个出错的查询，可以利用Exception的getTrace()方法，在异常处理器里记录完整的调用栈：

function handleUncaughtException($e){
    // 给用户展示通用错误页面
    header("Location: exceptionerror.php");
    ob_end_clean(); // 确保跳转生效，避免输出缓冲干扰
    
    // 构建详细的错误日志内容
    $error = "Uncaught Exception: " . date("Y-m-d H:i:s - ") . $e->getMessage() . "\n";
    $error .= "错误位置: " . $e->getFile() . " 第 " . $e->getLine() . " 行\n";
    
    // 添加调用栈追踪信息
    $error .= "\n调用栈追踪:\n";
    foreach ($e->getTrace() as $index => $trace) {
        $file = isset($trace['file']) ? $trace['file'] : '未知文件';
        $line = isset($trace['line']) ? $trace['line'] : '未知行';
        $func = isset($trace['function']) ? $trace['function'] : '未知函数';
        $class = isset($trace['class']) ? "{$trace['class']}::" : '';
        
        $error .= sprintf("#%d %s(%d): %s%s()\n", $index, $file, $line, $class, $func);
    }
    
    // 写入日志文件
    error_log($error, 3, "error_log.txt");
    exit;
}

现在日志里会显示从出错点回溯到最初调用的完整路径，比如你能看到是user_login.php第25行调用了DB::run()，从而直接找到对应的查询语句。

四、针对你现有错误的快速排查提示 #

从你给出的两个错误来看：

• 第一个错误near 'username'：大概率是SQL里的条件写错了，比如可能写成了WHERE 'username'而不是WHERE username = ?，或者占位符和参数数量不匹配。有了SQL日志后一眼就能看出来。
• 第二个错误near '86.28.135.16'', donated=0...：看起来是手动拼接了IP地址到SQL里（没使用参数绑定），导致引号没有正确转义。记得所有动态值都要用?占位符，不要直接拼进SQL。

最后 #

虽然单例类不是最佳实践，但在迁移阶段用它来加快进度是完全没问题的。等所有错误都修复完，再考虑重构为依赖注入之类的更优雅的方案也不迟。

内容的提问来源于stack exchange，提问作者M-jay