MySQL字符串拼接SQL必然导致注入，因用户输入与SQL逻辑未分离；必须用PDO::prepare()或mysqli_prepare()预处理，将SQL模板与参数彻底隔离，且表名、字段名等需白名单校验。
为什么 mysql_query() 拼接 SQL 就是危险的
因为用户输入直接混进 SQL 字符串里，数据库分不清哪部分是逻辑、哪部分是数据。比如用户名填 ' OR 1=1 -- ，拼出来就变成 SELECT * FROM users WHERE name = '' OR 1=1 -- '，整张表被查出来。
这不是“可能被攻击”，而是只要用字符串拼接 + 用户输入，就一定存在注入风险，哪怕加了 addslashes() 或 htmlspecialchars() 也拦不住绕过手段。
-
addslashes()对 MySQLi / PDO 的多字节编码、宽字符等场景完全失效 -
mysql_*()函数已彻底废弃（PHP 7.0+ 移除），连连接都建不了 - 前端校验纯属心理安慰，后端没处理等于裸奔
必须用 PDO::prepare() 或 mysqli_prepare()
预处理语句把 SQL 模板和数据彻底分开：数据库先编译带占位符的 SQL，再把参数当纯数据绑定进去，根本不会去解析它的语法含义。
两种写法都能防注入，但 PDO 更通用（支持多种数据库），MySQLi 更轻量（只对 MySQL）。别混用——比如用 PDO 连接却调 mysqli_real_escape_string()，毫无意义。
立即学习“PHP免费学习笔记（深入）”；
- 占位符只能是
?（位置式）或:name（命名式），不能拼成"?{$id}"或"'$id'" -
bind_param()的类型标识（如"s"、"i"）必须和实际变量类型匹配，否则可能转成空字符串或 0 - 不要在
prepare()前对参数做任何“过滤”或“转义”，预处理本身已足够
示例（PDO）：
$stmt = $pdo->prepare("SELECT * FROM users WHERE status = ? AND level > ?");
$stmt->execute(['active', 5]);
哪些地方容易漏掉预处理
不是只有 SELECT 才要防，所有带用户输入的增删改查都得走预处理。最容易翻车的是动态字段、动态表名、ORDER BY 和 LIMIT 后的值。
- 表名、字段名、排序方向（
ASC/DESC）不能用占位符，必须白名单校验，比如in_array($sort, ['name', 'created_at']) -
LIMIT参数如果是用户传的数字，要用(int)强转或filter_var($n, FILTER_VALIDATE_INT)，不能直接塞进? - 批量插入时，别写一个
prepare()然后循环execute()—— 应该用INSERT ... VALUES (?,?), (?,?)一次性绑多组 - ORM（如 Laravel Eloquent）默认防注入，但手写
whereRaw()或DB::statement()时，照样得自己处理参数
为什么 bindValue() 和 bindParam() 有区别
简单说：bindValue() 绑定的是值的副本，bindParam() 绑定的是变量本身（引用）。大多数时候用 bindValue() 更安全、更符合直觉。
- 循环中重用同一个
bindParam()变量，如果变量内容变了，执行时取的是最新值，容易出错 -
bindParam()要求变量必须存在且不能是表达式（比如不能写bindParam(1, $user['id'] + 1)） - 查询条件里用数组？PDO 支持
execute($array)，但 MySQLi 不支持，得手动展开成多个?
示例（安全写法）：
$stmt = $pdo->prepare("UPDATE logs SET message = ? WHERE id = ?");
$stmt->bindValue(1, $msg, PDO::PARAM_STR);
$stmt->bindValue(2, $id, PDO::PARAM_INT);
$stmt->execute();
预处理不是加个函数就完事，关键在「SQL 结构固定、数据完全隔离」。一旦开始拼接字段名、跳过类型检查、或者在 prepare 之外又加一层 escape，防线就从根上松动了。
