最有效的SQL注入防御方式是使用参数化查询。它通过数据库驱动预编译绑定将用户输入作为数据而非代码处理，需配合占位符与绑定方法（如Python的?、Java的PreparedStatement），动态结构部分须白名单校验，辅助手段仅作补充。
SQL注入最有效的防御方式是使用参数化查询，而不是拼接SQL字符串。核心在于把用户输入当作“数据”而非“代码”处理，让数据库引擎天然区分语义和值。
参数化查询怎么写才真正安全
关键不是加不加引号，而是是否交给数据库驱动做预编译绑定。比如在Python的red">sqlite3中：
- ✅ 安全写法：
cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,)) - ❌ 危险写法：
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'") - ⚠️ 注意：用
%s或:name等占位符本身不等于安全，必须配合驱动的参数绑定机制，不能自己字符串替换
不同语言/框架的常见误区
很多开发者以为用了ORM就绝对安全，其实不然：
- Django的
filter(name__exact=value)是安全的；但extra(where=[f"name='{value}'"])会直接拼接，高危 - MyBatis中
#{}走预编译，${}直接字符串替换——后者常被误用于动态表名、排序字段等场景 - Java JDBC的
PreparedStatement必须用setString()等方法赋值，不能用String.format()构造SQL
哪些地方容易漏掉防护
参数化只解决“值”的注入，但SQL结构本身（如表名、列名、ORDER BY字段）无法参数化：
- 动态表名/字段名：需白名单校验，例如
if sort_field not in ['created_at', 'score']: raise ValueError - LIKE模糊查询：参数化仍需注意通配符，应写成
WHERE name LIKE ?，然后传入'%'+keyword+'%'，而非在SQL里拼'%?%' - IN子句多个值：不能一个问号代替整个列表，需动态生成对应数量的占位符，如
WHERE id IN (?, ?, ?)，再逐一绑定
辅助手段不能替代参数化
过滤、转义、长度限制、WAF拦截都是补充，不是根本解法：
