用预处理语句（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 的钥匙。
