使用预处理语句（mysqli_prepare/PDO::prepare）并严格校验标识符是防SQL注入的唯一可靠方案，动态表名列名须白名单控制，参数绑定需显式指定类型，数据库权限与错误信息管理同样关键。
用 mysqli_prepare() 或 PDO::prepare() 是唯一靠谱做法
不拼接 SQL 字符串，就从源头掐断注入可能。手写 mysqli_real_escape_string() 或正则过滤字段名/表名，看似省事，实则漏得明明白白——它只处理字符串值，对列名、排序字段、LIMIT 偏移量等完全无效。
预处理不是“加个参数更安全”，而是让 MySQL 服务端把 SQL 结构和数据彻底分开解析：结构（含占位符）先编译，数据后绑定，中间根本不会被当 SQL 语句执行。
实操建议：
-
mysqli用户必须用mysqli_prepare()+mysqli_stmt_bind_param()，不能只调mysqli_query()拼接变量 -
PDO用户必须设PDO::ATTR_EMULATE_PREPARES => false，否则 PHP 会在本地模拟预处理，等同于字符串拼接 - 所有用户输入，包括
$_GET['id']、$_POST['sort']、分页的$_GET['offset']，只要进 SQL，就必须走绑定参数或白名单校验
动态表名/列名不能用 ? 占位，必须白名单硬控制
预处理的 ? 和 :name 只能代入值（value），不能代入标识符（identifier）——比如 SELECT * FROM ? 会直接报错，MySQL 不允许。
常见错误现象：SQLSTATE[42000]: Syntax error or access violation，尤其在尝试用占位符替换 ORDER BY 字段或 WHERE 中的列名时。
正确做法只有两个：
- 把允许的列名/表名写死成数组，用
in_array($user_input, $allowed_columns)校验，不匹配就拒掉 - 用
ctype_alnum()或正则/^[a-zA-Z_][a-zA-Z0-9_]*$/严格检查是否为合法标识符，再拼进 SQL（仅限绝对可控字段，如固定配置里的表前缀）
PDO::prepare() 绑定参数类型不写默认是 PARAM_STR，但数字类型要显式指定
比如 $stmt->bindValue(':id', $_GET['id'], PDO::PARAM_INT)，不写第三个参数，PDO 会把数字当字符串传过去，MySQL 虽然通常能隐式转换，但在某些场景下会失效（比如联合索引中数字字段未走索引、JSON 字段比较失败）。
更麻烦的是，PDO::PARAM_BOOL 和 PDO::PARAM_NULL 完全不能靠自动推断——布尔值不显式标类型，可能被当成整数 1/0，而 null 不标类型会被当成空字符串。
实操建议：
- 整数一律用
PDO::PARAM_INT - 布尔值用
PDO::PARAM_BOOL，别依赖(bool)$val - 明确要传
NULL时，用PDO::PARAM_NULL，不要传''或'null'
预处理不是万能的，事务和权限设计才是最后一道防线
即使每条查询都用了预处理，如果数据库账号有 DROP TABLE 权限，又恰好某处写了 mysqli_query("DROP TABLE " . $table_name)，白名单没兜住，照样完蛋。
所以真正防住注入，靠的是三层：
- 代码层：所有用户输入进 SQL 必须绑定或白名单
- 数据库层：应用账号只给
SELECT/INSERT/UPDATE/DELETE，禁用ALTER/DROP/EXECUTE - 架构层：敏感操作（如删用户）走独立接口+二次确认+操作日志，不依赖单条 SQL 的“安全性”
最容易被忽略的一点：开发环境常开 display_errors = On，一旦 SQL 报错，错误信息里可能直接暴露表结构或路径——攻击者不用注入，看报错就能画出数据库轮廓。上线前务必关掉。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
