用 prepare() + execute() 是唯一靠谱路径，参数必须完全隔离于 SQL 字符串外，命名参数更安全且支持复用；quote() 不能替代预处理，表名/字段名/ORDER BY 等需白名单校验。
用 prepare() + execute() 是唯一靠谱路径
不拼接 SQL，不手动转义，不信任任何用户输入——这应该是 PDO 防注入的铁律。只要用了 prepare() 和 execute()，并且参数不混进 SQL 字符串里，PDO 就会把值当纯数据传给数据库驱动，绕过了解析阶段，天然就免疫了注入。
但最常见的错误是“半途而废”。比如只对部分参数用了占位符，或者把变量拼进 SQL 后再调用 prepare()。这两种做法都等于白做。
INSERT INTO users (name, email) VALUES (?, ?)✅ 正确：两个问号，配合execute([$name, $email])"INSERT INTO users (name, email) VALUES ('{$name}', '{$email}')"❌ 即使后面硬套prepare()也无效"SELECT * FROM users WHERE status = 'active' AND role = {$role}"❌$role已经被拼进去，prepare 也救不了
命名参数比问号更安全、更易维护
尤其在字段多、顺序容易搞混、或者同一参数需要复用多次时，用 :name、:email 这类命名参数，比单纯用 ? 更不容易出错，也方便后期调整 SQL 结构。
有个细节容易被忽略：命名参数必须带冒号，而且 execute() 传的数组键名要严格匹配（包括冒号）。
SELECT * FROM posts WHERE author_id = :id AND published = :statusexecute([':id' => $uid, ':status' => 1])✅ 冒号不能漏execute(['id' => $uid, 'status' => 1])❌ 不带冒号，参数根本不会绑定- 同一个命名参数可在 SQL 中间出现多次，
execute()里只需传一次值
不要用 quote() 或 real_escape_string() 替代预处理
quote() 是 PDO 自带的字符串转义方法，但它只生成带引号的字符串字面量，本质上不是预处理机制。问题在于，它很容易被误读成“我已经转义过了，所以安全了”，结果反而留下隐患。
典型的陷阱：$sql = "SELECT * FROM users WHERE name = " . $pdo->quote($name) —— 看上去是转义了，实际还是字符串拼接，而且类型不可控（比如数字字段用了 quote 会多包一层引号）。
quote()只适合极少数动态构建 SQL 片段的场景（比如动态表名/字段名），但这些场景本身就应该尽量避免- 表名、字段名、排序方向（
ASC/DESC）无法用占位符，必须靠白名单校验，不能指望quote() - 如果真要用
quote()，只能确保它只用于字符串值，并且后续仍要拼进完整 SQL——这种写法已经是一种妥协，不如重构为预处理
事务中批量操作也要坚持单条预处理
有人觉得“批量插入就该用一条 SQL”，然后拼出几十个 (?, ?, ?), (?, ?, ?)，再把所有值 flatten 成一个大数组。乍看高效，但极易因为数组长度错位导致绑定失败或数据错乱。
更稳的做法是循环调用 prepare()（复用同一个句柄）+ execute()。现代 PDO 和 MySQL 对重复 prepare 有缓存优化，性能差距远小于数据错乱的风险。
- 避免：
INSERT INTO log (msg, level, ts) VALUES (?, ?, ?), (?, ?, ?), ...+ 一次性execute($all_values) - 推荐：
foreach ($logs as $log) { $stmt->execute([$log['msg'], $log['level'], $log['ts']]); } - 如果真要极致批量，用
LOAD DATA INFILE或 ORM 的批量接口，而不是自己手拼多值 INSERT
最常被忽略的一点是：预处理防不住字段名、表名、ORDER BY 子句里的注入。这些地方没有占位符支持，只能靠硬编码或白名单映射。比如 $allowed_sorts = ['created_at', 'name']; if (!in_array($sort, $allowed_sorts)) die(); —— 这部分不写进预处理，就得单独守好。
