PHP项目中自定义查询类如何防SQL注入？

自定义SQL查询类必须强制走预处理绑定路径，禁止字符串拼接；所有用户输入参数须通过占位符传入，动态表名/字段名需白名单校验，IN语句要手动展开占位符，输入验证不能替代预处理。

直接用字符串拼接构建 SQL 的自定义查询类，哪怕加了 addslashes() 或 mysqli_real_escape_string()，也挡不住 SQL 注入——这不是加固问题，是架构缺陷。

自定义查询类必须强制走预处理绑定路径

很多团队写所谓“通用查询类”，底层仍用 mysql_query() 或 mysqli_query() 拼接字符串，再套一层方法名包装，本质没变。真正安全的自定义类，所有执行入口（如 select()、update()）内部必须调用 prepare() + execute()，且禁止开放原始 SQL 拼接接口。

• 类构造时就要持有已配置好的 PDO 或 MySQLi 实例，且该实例已禁用模拟预处理：PDO::ATTR_EMULATE_PREPARES => false
• 所有接受用户输入的参数（如 where 条件、limit 值、order 字段）必须通过占位符传入，不能在 SQL 字符串里插值
• 如果类提供 raw()、expr()、setSql() 这类方法，必须默认禁用，或仅限白名单内固定语句（如 "NOW()"）

动态表名/字段名必须白名单硬校验

预处理占位符 ? 和 :name 只能用于数据值，不能用于标识符（表名、列名、ORDER BY、GROUP BY）。自定义类若支持动态字段，就得提前约定允许范围，运行时只做匹配，不作任何转义。

• 例如排序字段：先定义 $allowedSortFields = ['id', 'created_at', 'status']，再用 in_array($_GET['sort'], $allowedSortFields) ? $_GET['sort'] : 'id'
• 表名映射更稳妥：$tableMap = ['user' => 'users', 'order' => 'orders']; $realTable = $tableMap[$_GET['type']] ?? 'users';
• 绝对不要用 filter_var($input, FILTER_SANITIZE_STRING) 处理字段名——它删 HTML 标签，不防 SQL 注入

IN 语句和批量参数要手动展开占位符

预处理不支持数组直接绑定到 IN (?)，自定义类若封装了 whereIn()，必须动态生成对应数量的 ?，再把数组值平铺进参数列表。

立即学习“PHP免费学习笔记（深入）”；

• 错误写法："WHERE id IN (?)", [$ids] —— 这只会把整个数组转成字符串，变成 IN ('Array')
• 正确做法：先用 str_repeat('?,', count($ids) - 1) . '?' 构造占位符串，再用 array_values($ids) 提取纯数值参数
• 注意类型一致性：整数数组就用 bind_param('i', ...)，字符串数组用 's'，混合类型需拆开处理

别信“输入验证能替代预处理”

有人觉得“我用了 filter_var($id, FILTER_VALIDATE_INT)，拼接就安全了”，这是错觉。整数校验防不了逻辑绕过（比如传 -1 OR 1=1），也防不了字符集攻击（如宽字节截断），更防不了业务层误用（比如把校验过的 ID 当用户名拼进另一个查询）。

• 输入验证是必要补充，不是替代方案：数字转 (int)、邮箱用 FILTER_VALIDATE_EMAIL、长度超限直接 return false
• 但只要代码里还存在 "SELECT * FROM {$table} WHERE id = " . $id 这种模式，验证就形同虚设
• 最危险的是“半预处理”：部分参数绑定，部分拼接——攻击者会专攻未绑定的那部分

真正难的不是写对一个 prepare()，而是让整个查询类的所有分支路径都走同一套绑定机制，且不允许任何例外。一旦放开一个口子（比如为“兼容旧逻辑”加个 unsafeRawQuery()），整套防护就归零。