用 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 = :status-
execute([':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(); —— 这部分不写进预处理，就得单独守好。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
