防止sql注入最有效的方式是使用预处理配合参数化查询，而非拼接sql；需禁用动态表名/字段名拼接，改用白名单校验；数据库账号应遵循最小权限原则并屏蔽错误信息。
防止SQL注入最有效的方式是不拼接SQL语句，而是使用预处理（Prepared Statements）配合参数化查询。这是PHP操作数据库时保障安全的基石，不是“可选技巧”，而是必须遵循的标准做法。
用PDO或MySQLi启用预处理
原生字符串拼接（如 "SELECT * FROM user WHERE id = " . $_GET['id']）直接暴露在注入风险下。正确做法是把SQL结构和数据完全分离：
- PDO示例：`$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ? AND status = ?");`
`$stmt->execute([$_POST['email'], 1]);` - MySQLi面向对象示例：`$stmt = $mysqli->prepare("INSERT INTO logs (action, ip) VALUES (?, ?)");`
`$stmt->bind_param("ss", $action, $ip);`
`$stmt->execute();`
问号占位符（或命名参数如 :email）由驱动自动转义并绑定类型，攻击者无法突破SQL语法边界。
过滤输入不能替代预处理
用 htmlspecialchars()、filter_var() 或正则过滤用户输入，只适用于输出显示或简单校验，不能用于构造SQL。例如：
-
intval($_GET['id'])看似安全，但仅适用于整数字段，且掩盖了设计缺陷——本就不该让ID参与字符串拼接 -
addslashes()或mysql_real_escape_string()（已废弃）已被证明在多字节编码等场景下可能失效
过滤是辅助手段，不是SQL安全的主力。重心必须放在“不拼接”上。
避免动态表名/字段名，必要时白名单校验
预处理无法绑定表名、列名或ORDER BY字段。若业务真需动态指定（如多租户切换表），绝不可直接插入变量：
- 错误：
$sql = "SELECT * FROM " . $_GET['table'] . " WHERE id = ?";` - 正确：限定可选范围，用白名单判断
`$allowed_tables = ['users', 'posts', 'comments'];`
`$table = in_array($_GET['table'], $allowed_tables) ? $_GET['table'] : 'users';`
`$sql = "SELECT * FROM {$table} WHERE id = ?";`
没有绝对安全的“动态拼接”，只有受控的、穷举的、显式声明的选项。
最小权限原则 + 错误信息屏蔽
数据库账号权限要严格限制。应用账号只需 SELECT/INSERT/UPDATE 必需表，禁用 DROP、UNION、LOAD_FILE 等高危操作权限。同时关闭详细错误输出：
- 开发环境可开
display_errors=On，生产环境务必设为Off，改用日志记录 - 避免泄露表结构、字段名、数据库版本等敏感信息，防止攻击者辅助构造注入语句
基本上就这些。不复杂，但容易忽略。坚持用预处理，守住SQL结构和数据的边界，99%的注入风险自然消失。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
