用预处理语句（Prepared Statements）代替字符串拼接
SQL注入的根本原因是把用户输入直接拼进 SQL 字符串里，让恶意输入变成可执行代码。mysqli 和 pdo 都支持预处理，这是最有效、最通用的防御手段。
-
PDO::prepare()和mysqli_prepare()会将 SQL 结构和数据分离，数据库引擎只把参数当值处理，不解析为语法 - 不要用
mysql_real_escape_string()（已废弃）或手动加引号+转义，它在多字节编码、宽字符等场景下可能失效 - 即使参数是数字，也要用绑定（
bind_param()或bindValue()），别用(int)$id后再拼接，类型强制不能替代参数化
/* PDO 示例 */ $stmt = $pdo->prepare("select * FROM users WHERE username = ? AND status = ?"); $stmt->execute([$user_input, 'active']);限制数据库账户权限，遵循最小权限原则
一个 Web 应用连接数据库的账号，不应该拥有 DROP table、CREATE USER、FILE 等高危权限，否则一旦被绕过 SQL 注入防护，后果更严重。
- 创建专用账号：例如
app_rw@'10.0.1.%'，只允许从应用服务器网段连接 - 只授予必要权限：
GRANT SELECT, INSERT, UPDATE ON mydb.users TO 'app_rw'@'%';，不给delete或跨库权限 - 禁用
FILE权限（防止LOAD DATA INFILE或SELECT ... INTO OUTFILE泄露配置文件） - 避免使用
root或同等级账号跑应用逻辑，哪怕密码再复杂也不行
关闭危险配置项与默认账户
MySQL 默认配置偏宽松，有些选项会放大注入后的危害，必须显式关闭。
- 确认
secure_file_priv不为空（如设为/var/lib/mysql-files/），禁止任意路径读写文件 - 设置
sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，避免隐式类型转换导致绕过检查 - 删除或重命名
mysql.user表中空用户名、' '用户、或 host 为%的弱权限测试账号 - 禁用
local_infile（启动时加--local-infile=0或配置文件设local_infile = OFF）
应用层额外加固：输入校验 + 错误屏蔽
预处理和权限控制是核心，但应用层配合能进一步压缩攻击面。
- 对 ID 类参数优先用白名单正则（如
/^d+$/）或强类型转换后二次校验，不是所有地方都适合用预处理（比如ORDER BY字段名） - 绝不把 MySQL 原始错误信息（如
"You have an Error in your SQL syntax..."）返回给前端，容易暴露表结构或版本 - Web 服务器层（如 nginx）可加简单规则拦截常见注入关键词（
union select、sleep(、benchmark(），但不能依赖它防注入，仅作辅助探测 - 注意 ORM 框架是否真正用了预处理——有些“查询构造器”在拼接 where 条件时仍可能动态插字符串，要查文档或看生成 SQL
实际中最容易被忽略的是权限粒度和 secure_file_priv 配置。很多团队花大量时间写过滤函数，却让应用账号拥有 FILE 权限，等于给攻击者配好了上传 webshell 的钥匙。