pdo::attr_emulate_prepares => false必须显式关闭，否则pdo退化为字符串拼接，宽字节等场景下易被绕过；绑定参数需严格匹配类型与引用，表名等标识符须白名单校验。
用 PDO::prepare() + bindValue() 或 execute() 绑定参数是当前唯一可靠、可落地的防 SQL 注入方式。其他方法（比如 addslashes()、mysql_real_escape_string()）要么已废弃，要么在宽字节、字符集错配等场景下会被绕过。
为什么 PDO::ATTR_EMULATE_PREPARES => false 必须显式关闭
PHP 默认开启模拟预处理（emulate prepares），即 PDO 把占位符替换成字符串再发给 MySQL —— 这本质上还是拼接，只是换了个写法。一旦遇到 GBK 等多字节编码或连接层未设 charset，'%df' OR 1=1 -- 这类宽字节注入就能穿透。
- 必须在构造
PDO实例时传入：[PDO::ATTR_EMULATE_PREPARES => false, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] - 不设
PDO::ATTR_ERRMODE，绑定失败或执行出错时会静默失败，你根本不知道防护已失效 - 用
var_dump($pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES))可验证是否生效
bind_param() 在 MySQLi 中的类型和引用陷阱
MySQLi 的 bind_param() 看似简单，但两个细节错一个就白忙：类型字母必须对、变量必须传引用。
- 类型标识只能是
i（int）、d（double）、s（string）、b（blob）；写成'si'却传了两个字符串，第二个值会被截断或丢弃 - 参数必须是变量引用：
$stmt->bind_param('ss', $ip, $action)，不能写成bind_param('ss', $_SERVER['REMOTE_ADDR'], $_POST['action'])，否则报Number of variables doesn't match number of parameters - 别混用：
bind_param()已经做了安全绑定，再对同一变量调mysqli_real_escape_string()不仅多余，还可能因二次转义导致数据异常
表名、字段名、ORDER BY 为什么不能参数化
SQL 语法规定：占位符 ? 或 :name 只能用于数据值，不能用于标识符（identifier）。数据库在 prepare 阶段就要解析语句结构，而表名/排序字段属于结构的一部分。
- 错误写法：
SELECT * FROM ? WHERE status = ?→ 直接报错 - 正确做法：白名单硬校验，例如
in_array($_GET['sort'], ['id', 'name', 'created_at'], true)，不匹配就拒掉或 fallback 到默认字段 - 动态
LIKE模糊查询需注意：通配符（%、_）要由 PHP 拼进变量值里，再绑定，而不是写死在 SQL 中，否则会失去索引加速效果
最常被忽略的是：即使用了预处理，也得校验输入类型和范围。比如 $_GET['limit'] 是数字，但攻击者可能传 999999999999 导致全表扫描；$_POST['email'] 即使绑定了，也得先用 filter_var($email, FILTER_VALIDATE_EMAIL) 过一遍——预处理防的是语法篡改，不是业务逻辑崩坏。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
