预处理语句安全的关键在于数据库服务端的物理隔离而非仅调用prepare()函数：sql结构预编译固化，占位符仅作数据槽位，参数以二进制单独绑定不参与解析；pdo需同时满足禁用模拟预编译、所有输入进占位符、显式指定绑定类型三条件；mysqli绑定参数须严格匹配类型字符串、变量引用及类型标识；order by字段、limit偏移量、表名列名等影响sql结构的位置必须用白名单或intval()校验，预处理无效。
预处理语句不是“调了prepare()就安全”
它防注入的根源不在函数名，而在数据库服务端执行流程的物理隔离：SQL结构在预编译阶段就被固化成语法树，占位符?或:name只被识别为“纯数据槽位”，后续传入的参数以二进制形式单独绑定，不参与任何SQL解析。这意味着"1 OR 1=1"传给id = ?时，数据库只把它当字符串或整数处理，绝不会重写WHERE逻辑。
PDO::prepare() 安全的三个硬性条件缺一不可
漏掉任一环，PDO::prepare()就退化成普通字符串拼接：
-
PDO::ATTR_EMULATE_PREPARES => false必须显式设置——否则PDO自己模拟预编译，绕过MySQL服务端真实预编译，宽字节等场景下可能被绕过 - 所有外部输入必须进占位符，不能出现在SQL字符串里：错误写法
$pdo->prepare("WHERE name = '{$_POST['name']}'")，prepare白调 - 绑定时必须指定类型：
bindValue(1, $_POST['id'], PDO::PARAM_INT)，而非依赖自动转换；数字字段用PDO::PARAM_STR可能截断或转0
mysqli_prepare() 绑定参数的常见翻车点
bind_param()对变量形态和类型标识极其敏感，报错往往不提示原因：
- 类型字符串（如
"si"）长度、字母顺序必须与后续变量数量和类型严格一致，多一个少一个都触发Number of variables doesn't match number of parameters - 后续变量必须是已赋值的变量名，且带引用符号
&$email；bind_param("s", $_POST['email'])会失败 - 整数必须用
i，字符串用s，布尔用b——错用s传数字，值可能变空或0，且无警告
预处理救不了的地方，得靠白名单和intval()
占位符只能塞在VALUES、WHERE、SET右侧，凡是影响SQL结构的位置，预处理完全无效：
-
ORDER BY后字段名：必须白名单校验，in_array($_GET['sort'], ['created_at', 'status'], true) -
LIMIT偏移量：必须intval($_GET['offset'])后再拼接，且上限硬编码限制（如max(0, min(1000, $offset))） - 表名、列名、
UNION SELECT结构：一律禁止用户输入，动态表名必须映射到预设枚举
真正危险的从来不是“怎么写prepare”，而是以为写了prepare就万事大吉，结果把$_GET['table']直接拼进"SELECT * FROM {$_GET['table']}"——这种地方，连PDO::PARAM_STR都救不了。
