如何提高SQL代码的安全性：定期重构消除动态SQL隐患
为什么拼接字符串执行SQL总在凌晨出问题
这事儿说来有点讽刺：动态SQL之所以危险，恰恰是因为它把最关键的参数校验和语义解析，一股脑儿推迟到了运行时。数据库引擎根本没机会提前做预编译优化，攻击者只要瞅准时机，混入一个经典的 ' OR 1=1 --，就能轻松绕过所有业务层的苦心设计。
翻翻错误日志，你常会看到这样的代码：mysql_query("SELECT * FROM users WHERE name = '" + user_input + "'")。单看日志，一切风平浪静。可一旦 user_input 变成了 admin' --，整张用户表就等于在攻击者面前“裸奔”了。
那么，哪些场景最容易“图省事”而踩坑呢？老系统打补丁、数据导出功能的条件拼接、管理后台的模糊搜索——这些地方往往是重灾区。记住几个铁律：
- 永远优先采用参数化查询，哪怕为此多写几行代码，这笔账也绝对划算。
- 如果某些场景（比如动态
ORDER BY字段）实在避不开拼接，那就严格采用白名单机制，只允许预设范围内的值。别迷信任何正则过滤，那玩意儿靠不住。 - 绝对禁止把用户输入直接塞进
IN子句。正确的做法是，使用WHERE id IN (?, ?, ?)这样的模板，然后根据参数数量动态生成对应数量的占位符。
Python里用sqlite3或psycopg2怎么写才不翻车
这里有个高频误区：不是所有带了 %s 或 {} 的写法都叫参数化查询。错把字符串格式化当成参数化，是导致翻车的经典姿势。
来看一个错误示范：cursor.execute(f"SELECT * FROM logs WHERE level = '{level}'")。问题出在哪？f-string会先把变量值拼接到SQL字符串里，形成一个完整的语句，再交给数据库执行。这等于绕过了数据库驱动自身的参数化处理，让安全防火墙形同虚设。
正确的姿势应该是这样：
- 使用
sqlite3时，它只认?占位符：cursor.execute("SELECT * FROM users WHERE status = ?", (status,))。 - 使用
psycopg2（连接PostgreSQL）时，它接受%s作为占位符，但关键是要用元组或字典来传参：cursor.execute("SELECT * FROM orders WHERE user_id = %s", (user_id,))。 - 一条绝对红线：永远不要用
.format()或者 f-string 去填充SQL语句的任意部分。
Ja va的PreparedStatement为什么setString之后还被注入
遇到这种情况，根本原因通常不是 PreparedStatement
一个典型的错误模式是：先用 StringBuilder 把整个SQL语句拼好，然后再把这个拼接好的字符串，丢给 PreparedStatement 去执行。此时，预编译对象拿到手的已经是一个“成品”SQL，参数化机制早在拼接完成时就已经失效了。
这么干除了安全风险，还会带来性能问题：每次SQL字符串都不同，数据库无法复用执行计划，连接池的压力会陡然增加。
正确的做法必须牢记：
- SQL模板必须写死，只留
?作为占位符。甚至连字段名、表名都不能动态插入。 - 如果业务上确实需要动态表名怎么办？用白名单校验：
if (!Arrays.asList("orders", "users").contains(tableName)) throw new IllegalArgumentException();。 - 做批量插入时，别用循环多次执行同一条
PreparedStatement。应该改用addBatch()配合executeBatch()，这才是高效又安全的做法。
重构旧代码时怎么识别隐藏的动态SQL
重构老系统时，识别动态SQL是个技术活。别太相信代码注释，也别只靠grep搜索“+”或“&”号——真正危险的，往往是那些看起来“只是简单拼个变量”的角落。
有几个特别容易被忽略的点：
LIKE查询中直接拼接"%" + keyword + "%"。正确做法应该是用setString()方法，把完整的模糊匹配值（如“%keyword%”）作为一个参数传进去。- 存储过程调用里混入了字符串拼接，比如：
"CALL calc_balance('" + userId + "', '2024-01-01')"。 - ORM框架提供的原生SQL执行方法。例如，在MyBatis中，使用
${}（而不是#{}）语法，会导致变量值被直接拼接进SQL。
复杂之处在于，有些SQL的构建逻辑可能分散在好几个类里，中间还可能套着模板引擎。面对这种情况，重构前最务实的一步是：先把实际执行到数据库的SQL语句通过日志完整打印出来。对着这条真实的SQL进行分析，比在代码海里漫无目的地搜索要有效得多。
