真正可靠的SQL注入防护只有参数化查询，需用预处理语句分离SQL结构与数据；动态字段须白名单校验；ORM不自动免疫，避免raw()/extra()拼接用户输入。
SQL注入不是靠过滤能防住的
真正可靠的防护只有参数化查询。所谓“输入验证”“关键词过滤”在实战中基本无效——攻击者绕过它们比写个 SELECT 还快。你花半天写的正则黑名单，可能被一个 %00、/**/ 或双写 seleselectct 直接跨过去。
必须用预处理语句（Prepared Statements）
这是唯一被数据库驱动层原生支持、且无法被拼接绕过的机制。核心是把 SQL 结构和数据彻底分离，让数据库自己决定“哪部分是代码、哪部分是值”。
- PHP 用
PDO::prepare()或mysqli_prepare()，绝不用mysql_real_escape_string()（已废弃）或手动拼字符串 - Python 用
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，不写f"WHERE id = {user_id}" - Node.js 用
pg.query("SELECT * FROM logs WHERE level = $1", [level])，禁用client.query(`WHERE level = '${level}'`) - Java 用
PreparedStatement，别碰Statement+String.format
哪些场景容易误以为“安全”，其实很危险
动态表名、列名、排序字段、LIMIT 数值……这些不能参数化，但很多人硬塞进 ? 或 $1，结果报错后改用字符串拼接，还加个 strip_tags() 就以为万事大吉。
-
ORDER BY后的字段名：只能白名单校验，比如只允许["created_at", "status", "score"]，匹配不上就用默认值 - 表名/列名：用配置映射而非用户输入，如前端传
sort=price→ 后端查表得真实列名"product_price" -
LIMIT的数量：转成整数后范围检查，Math.min(Math.max(parseInt(n), 1), 100)，别直接插进 SQL - JSON 字段查询（如 PostgreSQL 的
->>）：值部分可参数化，路径部分仍需白名单
ORM 并不自动免疫 SQL 注入
很多开发者以为用了 Django ORM 或 SQLAlchemy 就高枕无忧，但只要调用了 extra()、raw()、text()、func.concat() 拼接用户输入，防线立刻崩塌。
- Django：
Model.objects.extra(where=["name = '%s'" % user_input])是典型雷区；应改用filter(name=user_input) - SQLAlchemy：
session.execute(text("SELECT * FROM users WHERE role = '" + role + "'"))错得离谱；必须用text("WHERE role = :role").bindparams(role=role) - 即使 ORM 支持表达式，
filter(User.name.ilike(f"%{keyword}%"))也比filter(User.name.ilike("%" + keyword + "%"))更安全（前者由 ORM 处理转义）
最麻烦的地方在于：SQL 注入漏洞往往不报错、不日志、不告警，它安静地把管理员密码拖走，或者悄悄把订单金额改成 0.01 元。别信“我这输入很简单”，只要进了 SQL 字符串拼接，就是开门揖盗。
