防止SQL注入的预编译参数化查询最佳写法

防止SQL注入最有效、最核心的手段就是使用预编译参数化查询（Prepared Statement / Parameterized Query）。它的原理非常简单：把SQL语句的结构和用户输入的数据完全分开处理，数据库在编译阶段只解析SQL骨架，用户数据作为纯参数传入，永远不会被当作SQL指令来执行。换句话说，攻击者就算在输入框里写了"'; DROP TABLE users;--"，数据库也只会把它当成一个普通字符串去匹配，而不是去执行删除操作。这不是什么新技术，而是从上世纪90年代就有的成熟方案，但直到今天，仍然有大量项目因为没用好它而被拖库。下面我会从原理、各语言具体写法、常见坑点、进阶技巧几个层面，把这件事讲透。

很多开发者习惯这样写查询：把用户输入直接拼进SQL字符串里。比如一个登录验证，代码写成"SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" + passInput + "'"。攻击者只要在用户名里输入 admin'--，SQL就变成了"SELECT * FROM users WHERE username = 'admin'--' AND password = 'xxx'"，后面的密码判断被注释掉了，直接绕过。这就是最经典的SQL注入。任何形式的字符串拼接、格式化、模板替换，只要把用户数据和SQL语句混在一起构建，都存在风险。预编译参数化查询从根本上杜绝了这个问题。

预编译的工作流程分两步。第一步，先把SQL语句的模板发送给数据库，其中用占位符（比如?、:name、$1等）代替具体值，数据库对这个模板进行语法解析和编译优化，生成执行计划。第二步，再把用户输入的实际值单独发送过去，数据库把这些值填入占位符位置，执行查询。因为SQL结构在第一步就已经固定了，第二步传入的数据无论是什么内容，都不可能改变SQL的逻辑结构。这就像你填一张已经印好格式的表格，不管你在格子里写什么字，表格的结构不会变。

Java生态里用得最多的是JDBC的PreparedStatement和MyBatis框架。先看原生JDBC的标准写法：

String sql = "SELECT * FROM users WHERE username = ? AND status = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, username);
pstmt.setInt(2, status);
ResultSet rs = pstmt.executeQuery();

这里要注意几个细节。第一，占位符用问号?，不要自己拼字符串。第二，setString、setInt这些方法会自动处理转义和类型，不需要你手动加引号。第三，参数索引从1开始，不是0。如果用MyBatis，写法更简洁，在Mapper XML里用#{}而不是${}：

<select id="getUser" resultType="User">
    SELECT * FROM users WHERE username = #{username} AND status = #{status}
</select>

重点强调：MyBatis中#{}是参数化查询，${}是字符串拼接，千万别搞混。用${}等于没做防护。

Python的DB-API规范要求所有数据库驱动都支持参数化查询。以psycopg2（PostgreSQL驱动）和pymysql（MySQL驱动）为例：

import psycopg2

conn = psycopg2.connect(dsn)
cur = conn.cursor()
cur.execute("SELECT * FROM users WHERE username = %s AND status = %s", (username, status))
rows = cur.fetchall()

import pymysql

conn = pymysql.connect(host='localhost', user='root', password='pwd', database='test')
cur = conn.cursor()
cur.execute("SELECT * FROM users WHERE username = %s AND status = %s", (username, status))
rows = cur.fetchall()

注意占位符的写法：PostgreSQL用%s，MySQL也用%s但有些驱动用%s或%(name)s命名参数。千万不要用f-string或者format去拼SQL，比如f"SELECT * FROM users WHERE username = '{username}'"这种写法，等于白写。

PHP推荐用PDO扩展，它原生支持预编译。写法如下：

$pdo = new PDO('mysql:host=localhost;dbname=test', 'root', 'password');
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND status = :status");
$stmt->execute(['username' => $username, 'status' => $status]);
$rows = $stmt->fetchAll();

PDO还支持问号占位符的写法，效果一样。另外，PHP的mysqli扩展也支持prepare，但PDO更通用、更推荐。如果你还在用mysql_query那种老函数，赶紧换掉，那个函数根本不支持参数化，天生有注入风险。

.NET平台用SqlCommand配合参数集合：

using (SqlConnection conn = new SqlConnection(connectionString))
{
    conn.Open();
    SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE username = @username AND status = @status", conn);
    cmd.Parameters.AddWithValue("@username", username);
    cmd.Parameters.AddWithValue("@status", status);
    SqlDataReader reader = cmd.ExecuteReader();
}

如果用Entity Framework，它默认就是参数化的，LINQ查询天然防注入。但如果你在EF里用FromSqlRaw写原生SQL，记得用参数化：

var users = context.Users.FromSqlRaw("SELECT * FROM users WHERE username = {0}", username).ToList();

EF会自动把{0}转成参数化查询，但你得确保传入的是参数而不是拼好的字符串。

Node.js的mysql2和pg（PostgreSQL驱动）都支持参数化：

const mysql = require('mysql2/promise');
const conn = await mysql.createConnection({host: 'localhost', user: 'root', database: 'test'});
const [rows] = await conn.execute('SELECT * FROM users WHERE username = ? AND status = ?', [username, status]);

const { Pool } = require('pg');
const pool = new Pool();
const res = await pool.query('SELECT * FROM users WHERE username = $1 AND status = $2', [username, status]);

Node.js开发者特别容易犯的错误是用模板字符串拼接SQL，比如"SELECT * FROM users WHERE username = '${username}'"，这在Node.js社区里太常见了，必须杜绝。

即使知道要用参数化查询，实际开发中还是有不少坑。第一个坑是动态拼接表名或列名。参数化查询只能对值（value）进行参数化，不能对表名、列名、ORDER BY方向这些结构性部分参数化。比如你想动态指定排序字段，不能写"ORDER BY ?"然后传"username"，这不行。正确做法是白名单校验：预先定义允许的列名列表，用户输入必须在列表里才能使用。第二个坑是LIKE模糊查询的通配符处理。如果你想做"%keyword%"的模糊搜索，应该在代码层面拼好通配符再传参，而不是在SQL里拼：

String keyword = "%" + userInput + "%";
pstmt.setString(1, keyword);

第三个坑是IN查询的处理。如果你要查"WHERE id IN (1,2,3)"，但这个列表是动态的，不能简单地把整个列表拼成一个参数。正确做法是根据列表长度动态生成对应数量的占位符，或者用数据库支持的数组类型（PostgreSQL支持数组参数）。第四个坑是框架的ORM有时候会绕过参数化，比如Hibernate的HQL如果用字符串拼接而不是setParameter，同样有注入风险。

预编译参数化查询是防止SQL注入的第一道也是最重要的一道防线，但不是唯一一道。作为资深开发者，我建议建立多层防御。第一层，所有数据库操作必须用参数化查询，这是底线，没有例外。第二层，输入验证和白名单，对用户输入做类型检查、长度限制、格式校验，比如年龄字段只允许数字，邮箱字段用正则校验。第三层，最小权限原则，数据库连接账号只给必要的权限，别用root账号跑业务，万一被注入了也限制破坏范围。第四层，使用WAF（Web应用防火墙）做额外的请求过滤，虽然不能替代代码层面的防护，但可以挡住大部分自动化扫描攻击。第五层，定期做安全审计和渗透测试，用SQLMap等工具自己测一遍，发现问题及时修。

防止SQL注入这件事，说难不难，说简单也不简单。难的是在整个团队、整个项目生命周期里持续坚持正确的写法。简单的是技术方案本身已经非常成熟，每种主流语言和框架都提供了完善的参数化查询支持。核心就一句话：永远不要把用户输入拼进SQL语句里，永远用占位符加参数绑定。把这个习惯刻进骨子里，SQL注入这个漏洞基本就跟你的项目无缘了。不管你用Java、Python、PHP、C#还是Node.js，上面给出的写法都是经过验证的最佳实践，直接拿去用就行。