不能直接拼接sql字符串是因为这会带来严重的sql注入风险，攻击者可以通过构造恶意输入改变sql语句的原始逻辑，从而窃取、篡改或删除数据库中的数据。正确的做法是使用预处理语句（prepared statements），将sql模板与数据参数分离，由数据库驱动负责安全的转义和绑定，确保用户输入仅被视为数据而非可执行代码。
直接拼接SQL会导致什么具体后果
直接拼接SQL字符串会让用户的输入直接嵌入到SQL命令中，如果输入中包含单引号或特殊关键字，就会破坏原有的SQL结构。例如，当用户名输入为 ' OR '1'='1 时，原本用于验证身份的查询会变成永真条件，导致未授权访问。这种漏洞是Web应用中最常见且危害最大的安全缺陷之一，因为它允许攻击者在数据库服务器上执行任意操作。
$username = $_POST['user']; $password = $_POST['pass']; $sql = "SELECT * FROM users WHERE username = '" . $username . "' AND password = '" . $password . "'"; $result = mysqli_query($conn, $sql); // 危险：直接执行拼接后的SQL
上述代码中，$username 和 $password 直接通过点号拼接进 $sql 变量。如果攻击者提交 admin'-- 作为用户名，SQL语句变为 SELECT * FROM users WHERE username = 'admin'--' AND password = '...'，注释符号 -- 使得后面的密码验证失效，攻击者无需密码即可登录。这种后果是不可逆的数据泄露或系统控制权丧失。
立即学习“PHP免费学习笔记（深入）”；
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
使用预处理语句如何避免注入风险
预处理语句通过占位符（如 ? 或命名参数）替代具体的值，先将SQL结构发送给数据库进行编译，然后再单独发送数据参数。数据库在编译阶段已经确定了SQL的逻辑结构，后续传入的参数无论包含什么字符，都只会被当作纯数据处理，不会改变SQL的执行计划。这种方式从根本上切断了输入与代码逻辑的联系，确保了查询的安全性。
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :user AND password = :pass');
$stmt->execute([':user' => $username, ':pass' => $password]);
$user = $stmt->fetch();
在PDO示例中，prepare() 方法接收带有 :user 和 :pass 占位符的SQL模板。随后 execute() 方法将实际的用户名和密码以数组形式绑定到这些占位符。即使 $username 包含恶意代码，它也被安全地包裹在引号内作为字符串值处理，无法干扰SQL语法。这种方法不仅安全，而且通常比手动转义更高效，因为数据库可以缓存预编译的执行计划。
在PDO中使用命名参数相比位置占位符有什么优势
在PDO中使用命名参数（如 :name）相比位置占位符（如 ?）的主要优势在于可读性和维护性。命名参数明确指出了每个值对应的字段含义，使得代码意图一目了然，特别是在涉及多个参数的复杂查询中。此外，命名参数允许在 execute() 中以任意顺序传递参数，只要键名匹配即可，这减少了因参数顺序错误导致的逻辑bug。
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :user AND email = :email');
$stmt->execute([':email' => $email, ':user' => $username]); // 顺序无关紧要
在这个例子中，execute() 数组中 :email 排在 :user 前面，但PDO会根据键名正确绑定，而不是按位置绑定。如果使用 ? 占位符，则必须严格按照SQL中出现的顺序提供参数，否则会导致类型不匹配或数据错位。对于大型项目或频繁修改的查询，命名参数能显著降低出错概率并提升代码清晰度。
