prepare防SQL注入是因为将SQL结构与数据分离，服务端先编译模板再单独传参，参数不参与SQL解析；但仅适用于DML语句，表名、列名等动态语法部分须用白名单校验。
为什么 prepare 能防 SQL 注入
因为 prepare 把 SQL 语句结构和数据彻底分开：服务端先编译语句模板，再用 execute 单独传参。参数不会被当 SQL 解析，就算传入 ' OR 1=1 -- 这种字符串，也只会作为普通值匹配，不会改变查询逻辑。
常见错误是以为 “拼接字符串 + 加单引号” 就安全，比如："SELECT * FROM user WHERE name = '" + name + "'" —— 这本质还是拼接，name 里带单引号或注释符照样崩。
- 必须用占位符
?（MySQLi）或命名参数:name（PDO），不能在 SQL 字符串里手动插变量 -
prepare本身不防注入，关键在后续的bind_param或execute传参方式 - 只对 DML（
SELECT/INSERT/UPDATE/DELETE）有效；建表、排序字段、表名这些动态部分无法用?占位，得靠白名单校验
MySQLi 中 prepare 的典型写法和易错点
很多人卡在参数类型绑定不对，导致查不到数据或报错 Number of variables doesn't match number of parameters。
- 占位符数量、
bind_param类型字符串长度、实际传参个数三者必须严格一致 - 类型字符用
s（string）、i（integer）、d（double）、b（blob），别把i写成int - 参数必须是变量，不能直接传字面量，比如
bind_param("s", "admin")会警告，得先$user = "admin"; bind_param("s", $user)
$stmt = $mysqli->prepare("SELECT id, name FROM user WHERE status = ? AND age > ?");
$stmt->bind_param("si", $status, $min_age);
$status = "active";
$min_age = 18;
$stmt->execute();
PDO 的 prepare 更灵活但默认不报错
PDO 默认开启模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），看起来用了 prepare，其实还是 PHP 拼接 SQL，根本没走 MySQL 的预处理机制 —— 这时候依然可能被注入，尤其在老版本 MySQL 或特殊字符场景下。
- 必须显式关闭模拟：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 命名参数更直观，但注意键名要带冒号：
:email，不是email -
fetch()前记得execute()，否则返回空结果，且无报错提示
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$stmt = $pdo->prepare("SELECT * FROM user WHERE email = :email AND role = :role");
$stmt->execute([':email' => $input_email, ':role' => $input_role]);
$user = $stmt->fetch();
哪些地方 prepare 根本用不了
表名、列名、ORDER BY 字段、LIMIT 的偏移量 —— 这些属于 SQL 语法结构的一部分，MySQL 不允许用 ? 占位。硬塞进去会直接报错 SQLSTATE[42000]: Syntax error or access violation。
- 动态表名/字段名必须走白名单过滤，比如：
in_array($table, ["user", "order", "log"]) ?: die("invalid table") -
LIMIT的数字参数可用intval()强转，但要注意负数和超大值（如9999999999）可能引发性能问题 - 排序方向（
ASC/DESC）不能参数化，只能限定为两个字符串之一
最麻烦的是多条件动态查询，比如“按姓名或邮箱模糊搜”，这时候要么拼 SQL（但字段名和操作符必须白名单），要么用 ORM 的 query builder，别指望 prepare 全包。
