mysqli_prepare()不能拼接变量，因预处理需SQL结构固定，拼接会绕过参数绑定；PDO::PARAM_STR与PARAM_INT区别在于数据类型传递方式，影响索引使用和安全性；获取自增ID须用mysqli_stmt_insert_id($stmt)；预处理仅防参数注入，表名等结构部分仍需白名单校验。
为什么 mysqli_prepare() 不能直接拼接变量
因为预处理语句的参数占位符（? 或命名占位符）在服务端解析时才绑定值，SQL 结构早已固定。一旦你用字符串拼接把变量塞进 SQL 字符串里，就绕过了预处理机制，等于白写。
常见错误现象：mysqli_prepare($conn, "SELECT * FROM users WHERE id = $id") —— 这根本没走预处理，$id 被直接插进去，mysqli_stmt_bind_param() 根本没机会生效。
- 正确做法：SQL 字符串里只出现
?，所有动态值通过mysqli_stmt_bind_param()单独传入 - 命名占位符（如
:name）需用PDO，mysqli原生不支持 - 注意类型字符必须匹配：
i（整数）、s（字符串）、d（浮点）、b（BLOB）
PDO::prepare() 绑定参数时 PDO::PARAM_STR 和 PDO::PARAM_INT 有什么区别
区别不在“转义”或“过滤”，而在底层数据类型传递方式和 MySQL 协议对字段类型的预期。错用会导致隐式转换失败、索引失效甚至报错 HY093。
使用场景：比如 WHERE status = ?，如果 status 是 TINYINT 字段，传 PDO::PARAM_STR 可能让 MySQL 拒绝使用索引；反过来，对 VARCHAR 字段传 PDO::PARAM_INT 会触发字符串截断或报错。
立即学习“PHP免费学习笔记（深入）”；
-
PDO::PARAM_STR：按字符串发送，MySQL 自行尝试转换（不推荐依赖） -
PDO::PARAM_INT：以整型二进制格式发送，避免字符串解析开销，也更安全 - 没有
PDO::PARAM_BOOL，布尔值要转成int再传 - 批量插入时，类型不一致容易导致某条语句失败而其余成功，难排查
执行 mysqli_stmt_execute() 后怎么拿到自增 ID
不能用 mysqli_insert_id($conn)，必须用 mysqli_stmt_insert_id($stmt)。因为 mysqli_insert_id() 读的是连接级状态，而预处理语句可能复用连接、跨事务，或者被其他查询干扰。
常见错误现象：多线程/并发环境下，A 语句刚插入，B 语句立刻调 mysqli_insert_id()，结果拿到的是 B 的 ID 或 0。
- 必须在
mysqli_stmt_execute($stmt)成功后，立即调mysqli_stmt_insert_id($stmt) - 该函数只对
INSERT/REPLACE有效，UPDATE或无自增字段返回 0 - 如果用了事务，
insert_id在COMMIT前就已确定，不会因回滚改变
预处理语句真的能防所有 SQL 注入吗
不能。它只防「参数值」注入，对「结构层」变动完全无效。比如表名、字段名、ORDER BY 子句、LIMIT 偏移量，都不能用 ? 占位。
典型翻车场景：$sql = "SELECT * FROM {$table} WHERE id = ?"，哪怕后面绑了参数，$table 仍是注入点；又比如 "ORDER BY {$sort_field}"，用户传 name ASC, (SELECT password FROM users LIMIT 1) 就直接脱库。
- 表名/字段名只能白名单校验：
in_array($table, ['users', 'posts'], true) -
LIMIT参数必须强制转整型：(int)$offset，且检查是否为非负 - 排序字段建议映射为固定选项：
$map = ['name' => 'username', 'time' => 'created_at'] - 预处理不是银弹，它只解决“值怎么进 SQL”，不解决“SQL 结构怎么生成”
最常被忽略的一点：开发者以为用了 prepare 就高枕无忧，结果在拼接 SQL 字符串时放松了对非参数部分的校验——那前面所有努力都归零。
