mysqli_prepare()更可靠因SQL结构与参数彻底分离，参数以二进制传入不参与解析，杜绝注入；而字符串拼接即使转义也可能被字符集、多语句或LIKE通配符绕过。
为什么 mysqli_prepare() 比拼接字符串更可靠
因为数据库驱动在执行 mysqli_prepare() 时，会把 SQL 结构和参数彻底分离：语句模板先编译，参数值后续以二进制方式传入，不参与语法解析。哪怕用户输入 admin' OR 1=1 --，它也只会被当作一个完整字符串值处理，不会触发逻辑翻转。
而直接用 mysqli_query() 拼接，PHP 层面的字符串操作完全暴露在攻击面下——哪怕加了 mysqli_real_escape_string()，也可能因字符集不一致（如 GBK 双字节截断）、多语句执行（MySQL 旧版允许分号）、或 LIKE 场景中通配符未转义，导致绕过。
mysqli_stmt_bind_param() 的类型参数不能乱写
绑定参数时传入的类型标识（"s"、"i"、"d"、"b"）必须与实际变量类型严格匹配，否则可能引发静默失败或类型截断：
-
"s"仅适用于字符串；整数用"i"，浮点数用"d" - 若对数字型字段误用
"s"，MySQL 可能隐式转换，但某些边界值（如超大整数）会丢失精度 - 绑定 NULL 值需用
mysqli_stmt_bind_param()配合引用变量，不能直接传null
示例正确写法：
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ? AND status = ?");
$stmt->bind_param("is", $user_id, $status); // id 是 int，status 是 string
预处理语句不是万能的，这些地方仍需手动防护
预处理只保护 WHERE、VALUES、SET 等参数化位置，但无法覆盖以下场景：
- 表名、字段名动态拼接（如
"SELECT * FROM {$table_name}"）→ 必须用白名单校验，禁止用户控制 - ORDER BY 后的字段或方向（
"ORDER BY {$sort_field} {$sort_dir}"）→ 只允许从预设枚举中选取 - LIKE 查询中的通配符（
%、_）→ 用户输入需用addcslashes($input, '%_')转义，再拼入LIKE ?占位符 - IN 子句多个值（
WHERE id IN (?, ?, ?)）→ 占位符数量必须提前确定，不能靠用户输入动态生成占位符串
连接层和权限配置是预处理失效后的最后一道闸
即使代码层用了 mysqli_prepare()，若数据库账号权限过大，一次成功的注入（比如通过报错注入猜出结构后构造合法语句）仍可能导致灾难性后果：
- 应用账号禁止
DROP、ALTER、CREATE、FILE、PROCESS等高危权限 - 读操作用只读账号，写操作换另一账号，且两账号均限制访问具体库表（如
GRANT SELECT ON app_db.users TO 'reader'@'%'） - MySQL 配置中关闭
secure_file_priv或设为NULL，防止通过LOAD DATA INFILE或SELECT ... INTO OUTFILE外泄文件
真正安全的防护链，是预处理语句 + 白名单字段控制 + 最小权限账号 + 错误信息屏蔽，四者缺一不可。少任何一个环节，都可能让看似牢固的防线出现裂口。
