SQL注入根源在于字符串拼接用户输入，参数绑定通过预编译将参数作为纯数据传递，杜绝参与语法解析；各语言均需用占位符（如?、%s、:name）而非字符串拼接。
SQL注入漏洞的根源在哪儿
问题不在SQL本身，而在字符串拼接时把用户输入直接塞进查询语句里。SELECT * FROM users WHERE name = ' + user_input 这类写法，只要user_input是' OR '1'='1，整条语句就变成SELECT * FROM users WHERE name = '' OR '1'='1'，绕过条件查出所有数据。
参数绑定不是“加一层防护”，而是从执行机制上切断恶意输入参与语法解析的可能——数据库驱动会把参数值当纯数据传给预编译语句，不参与SQL语法树构建。
不同语言里怎么写参数绑定
核心就一条：永远用占位符（? 或 :name），绝不拼字符串。具体写法因驱动而异，但逻辑一致：
- Python（
sqlite3）用?位置占位：cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) - Python（
psycopg2）支持%s和命名参数：cursor.execute("SELECT * FROM users WHERE status = %s", ("active",)) - Java（JDBC）只认
?：PreparedStatement stmt = conn.prepareStatement("DELETE FROM logs WHERE ts - Node.js（
pg）用$1编号：client.query("UPDATE accounts SET balance = $1 WHERE id = $2", [newBal, accountId])
注意：mysql2 默认开启multipleStatements时，即使用了?，攻击者仍可能用;闭合语句再追加恶意SQL——务必关掉：multipleStatements: false。
哪些地方容易漏掉参数绑定
最常翻车的是动态字段、表名、排序方向这类“不能参数化”的场景：
-
ORDER BY后的字段名：ORDER BY ?会报错，必须白名单校验：if (sortField !== 'created_at' && sortField !== 'score') throw new Error('invalid sort') - 表名或列名拼接：
INSERT INTO ${tableName}—— 没有安全的占位符方案，只能靠配置枚举或正则严格匹配（如^[a-z_][a-z0-9_]{2,31}$） - IN 子句多个值：
WHERE id IN (?, ?, ?)要手动拼占位符数量，别写成WHERE id IN (?)然后传数组——多数驱动不支持 - LIKE 模糊匹配：
WHERE name LIKE '%?%'是错的，? 会被当字面量；应先在代码里拼好'%' + userInput + '%'，再绑定
为什么 ORM 也不能完全放心
ORM 如 Django ORM、SQLAlchemy、Sequelize 默认用参数绑定，但留了“原生SQL接口”这个后门：
- Django 的
extra()、raw()；SQLAlchemy 的text()；Sequelize 的query()—— 这些方法若拼接用户输入，照样中招 - 链式查询看似安全，但
.filter(name__icontains=request.GET['q'])如果没对q做长度/字符限制，可能触发数据库正则拒绝服务（ReDoS） - 某些 ORM 的“表达式构造器”允许传入未过滤的字符串字面量，比如 SQLAlchemy 的
func.concat(User.name, " (", User.id, ")")中的括号是静态字符串，但若换成变量就得走绑定
真正难的不是学会execute(..., params)这行代码，而是每次拼SQL前下意识问一句：这个变量有没有可能来自外部？它出现在语法结构里的哪个位置？
