输入校验是Web应用安全的第一道防线，尤其对于直接操作数据库的PHP应用来说，用户提交的任何一个参数都可能成为SQL注入的突破口。很多安全事件的根因并不在于框架不够强，而在于开发者把用户的输入直接拼进了SQL语句。本文将从SQL注入的成因讲起，逐步给出PHP中切实可行的校验与防御方案。
一、SQL注入的成因与拼接查询的风险
SQL注入的本质，是把用户输入当作了SQL语法的一部分来执行。当开发者用字符串拼接的方式构造SQL时，攻击者只需要在输入中插入引号、注释符或者布尔表达式，就能改变原SQL的语义。举个例子，一段典型的登录代码：
// 危险写法：直接拼接用户输入 $username = $_POST['username']; $password = $_POST['password']; $sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; $res = mysqli_query($conn, $sql);
如果攻击者在用户名框输入admin' --，那么最终执行的SQL就变成了SELECT * FROM users WHERE username = 'admin' --' AND password = '...'，密码条件被注释掉，攻击者无需密码即可登录。更严重的情况下，攻击者可以利用UNION SELECT读取任意表的数据，甚至通过堆叠查询执行删除语句。
这类漏洞的特点是隐蔽且危害巨大：代码在测试环境下往往一切正常，因为正常输入不会触发注入点。但只要系统暴露在公网上，自动化扫描工具可以在几小时内找到漏洞。因此，防御的核心思路只有一条：让数据永远是数据，永远不参与SQL语法的解析。
二、预处理语句与参数绑定：最根本的解决方案
PDO和MySQLi都提供了预处理语句（Prepared Statement）支持，这是防御SQL注入最可靠的手段。预处理的工作原理是：SQL模板先发送给数据库完成语法解析，参数占位符的位置已经固定，之后再单独传输参数值。这样无论参数内容是什么，都只会被当作纯数据处理，不可能改变SQL结构。
推荐使用PDO，代码示例如下：
// 安全写法：PDO预处理 + 参数绑定
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', 'user', 'pass', [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false, // 关闭模拟预处理，确保真正的参数化
]);
$stmt = $pdo->prepare('SELECT id, username FROM users WHERE username = :username AND status = :status');
$stmt->execute([
':username' => $_POST['username'],
':status' => 1,
]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);
有两个细节容易被忽视。第一是PDO::ATTR_EMULATE_PREPARES，默认值为true时PDO会在本地模拟预处理，某些边界场景下仍有风险，建议显式关闭。第二是字符集必须写进DSN，也就是charset=utf8mb4，如果依赖SET NAMES设置字符集，在旧版本PHP中可能触发宽字节注入。
需要特别强调的是，预处理只能保护数据部分，不能保护表名、列名、排序方向这类SQL结构元素。例如ORDER BY ?绑定参数是不生效的，这类场景必须用白名单，下文会详细展开。
三、输入校验的分层策略：类型转换、白名单与过滤函数
参数绑定解决的是传输层的问题，而在应用层，对输入做严格校验同样重要。校验的意义在于：尽早拒绝明显非法的数据，减轻数据库压力，同时保证写入的数据符合业务预期。
第一种手段是类型强制转换。对于ID、页码、数量这类明确是数字的参数，直接转换成整数是最简洁有效的做法：
$id = (int) $_GET['id']; // 任何输入都会被转成整数 $page = max(1, (int) $_GET['page']); $pageSize = min(100, max(1, (int) $_GET['page_size'])); // 限制范围，防止大分页拖垮数据库
第二种手段是白名单校验。凡是会被拼进SQL的结构性内容，比如排序字段、排序方向，都必须走白名单。以列表页的动态排序为例：
// 排序字段白名单
$allowedFields = ['created_at', 'price', 'sales'];
$allowedOrder = ['ASC', 'DESC'];
$field = in_array($_GET['sort'], $allowedFields, true) ? $_GET['sort'] : 'created_at';
$order = in_array(strtoupper($_GET['order'] ?? ''), $allowedOrder, true) ? strtoupper($_GET['order']) : 'DESC';
// 结构部分使用白名单值拼接，数据部分使用占位符
$stmt = $pdo->prepare("SELECT id, title, price FROM goods ORDER BY {$field} {$order} LIMIT :limit OFFSET :offset");
第三种手段是针对字符串的过滤与校验。PHP提供了filter_var系列函数，例如filter_var($email, FILTER_VALIDATE_EMAIL)可以校验邮箱格式，filter_var($url, FILTER_VALIDATE_URL)可以校验URL。对于用户名这类自由文本，建议用正则限定字符集，比如只允许字母数字下划线：
if (!preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)) {
exit('用户名只能为3-20位字母、数字或下划线');
}
需要注意的是，很多教程会推荐addslashes或者str_replace手动转义引号，这种做法不建议使用。手动转义对各类数据库方言的覆盖不完整，容易出现遗漏，而且在不同的字符集环境下行为不一致。转义的责任应该交给预处理机制，应用层专注做类型和格式的校验。
四、典型场景实战：注册、搜索与动态表名
用户注册是写入数据最频繁的场景，正确的做法是先校验格式，再通过预处理写入，同时利用数据库唯一索引防止重复注册：
$username = trim($_POST['username'] ?? '');
$password = $_POST['password'] ?? '';
// 1. 格式校验
if (!preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)) {
exit('用户名格式不正确');
}
if (strlen($password) < 8) {
exit('密码长度至少8位');
}
// 2. 密码单独处理：哈希存储，绝不入库明文
$hash = password_hash($password, PASSWORD_DEFAULT);
// 3. 预处理写入
$stmt = $pdo->prepare('INSERT INTO users (username, password, created_at) VALUES (:u, :p, NOW())');
$stmt->execute([':u' => $username, ':p' => $hash]);
搜索场景的难点在于模糊查询的通配符。LIKE的%和_是用户可能输入的字符，如果不处理，用户输入百分号就能导致全表扫描。标准做法是先转义通配符，再绑定参数：
$keyword = $_GET['kw'] ??;
// 转义LIKE通配符
$keyword = str_replace(['\\', '%', '_'], ['\\\\', '\\%', '\\_'], $keyword);
$stmt = $pdo->prepare('SELECT id, title FROM articles WHERE title LIKE :kw LIMIT 20');
$stmt->execute([':kw' => '%' . $keyword . '%']);
动态表名场景原则上应该避免，如果业务确实需要按月分表，可以用sprintf配合严格的格式化来生成表名，保证表名只来自服务端变量而不来自用户输入：
// 表名由服务端计算，与用户输入无关
$table = 'logs_' . date('Ym');
$stmt = $pdo->prepare("SELECT * FROM {$table} WHERE user_id = :uid");
$stmt->execute([':uid' => $_SESSION['user_id']]);
五、上线前自查清单
最后把关键要点整理成一份清单，方便在代码审查时逐项核对：
- 全站搜索字符串拼接SQL的写法，重点排查
.$_GET、.$_POST、.$_REQUEST这类模式，全部替换为预处理语句。 - PDO连接中显式设置
PDO::ATTR_EMULATE_PREPARES => false，并在DSN中写明charset=utf8mb4。 - 所有数字型参数做
(int)强制转换，并限制合理范围，比如分页大小上限。 - 表名、列名、排序字段一律使用白名单，绝不接受用户输入直接拼接。
- LIKE查询先转义通配符，再绑定参数。
- 数据库账号遵循最小权限原则，应用账号不授予DROP、GRANT等高危权限。
- 错误信息不直接输出到页面，生产环境关闭
display_errors，防止SQL结构泄露。
输入校验不是一次性工作，而是需要贯穿整个开发周期的习惯。预处理语句负责守住数据层的安全底线，类型转换和白名单负责应用层的合法性把关，两者配合使用，才能让PHP应用在面对注入攻击时站稳脚跟。把校验逻辑封装成统一的入口层，让团队成员不必每次都手动处理，也是保持长期安全性的有效做法。