SQL注入风险源于字符串拼接使用户输入被当作SQL代码执行，预编译通过参数与语句分离从语法层面阻断，所有用户输入必须进参数，动态字段需白名单校验，ORM原生SQL或日志拼接同样危险。
为什么 string.Format 或拼接 SQL 字符串会直接导致删库
因为数据库把拼进去的字符串当真实 SQL 执行，' OR 1=1; DROP TABLE users; -- 这种输入，后端一拼就变成完整可执行语句。预编译不是“过滤”，而是从语法层面切断变量和 SQL 结构的混合——参数永远只是值，不会被解析成关键字或语句。
常见错误现象：System.Data.SqlClient.SqlException: Incorrect syntax near 'xxx' 或更危险的静默执行成功；用 WHERE name = '{input}' 查用户时，输 admin'-- 就绕过密码。
- 所有用户可控输入都必须进参数，包括分页
offset、limit、ORDER BY字段名（后者需白名单校验，不能参数化） - .NET 中
SqlCommand的Parameters.Add()比AddWithValue()更安全——后者可能推断错类型，引发隐式转换或索引失效 - Java 的
PreparedStatement必须用?占位，不能写成"WHERE id = ? AND status = '" + status + "'"
MySQL/PostgreSQL 中 PreparedStatement 的实际写法差异
MySQL 官方驱动默认关闭服务端预编译，useServerPrepStmts=true 才真正走二进制协议；PostgreSQL 的 Npgsql 默认启用，但参数名必须用 @name（SQL Server 风格）或 :name（原生风格），混用会报 42703: column "xxx" does not exist。
使用场景：批量插入、动态条件查询、存储过程调用。
- MySQL 连接字符串加
;useServerPrepStmts=true;cachePrepStmts=true，否则Prepare()只是客户端模拟 - PostgreSQL 中
WHERE name ILIKE :pattern，参数名冒号不能漏；ILIKE是 PostgreSQL 特有，MySQL 要用LOWER(name) LIKE LOWER(:pattern) - Oracle 的
:name和 SQL Server 的@name不互通，换数据库时别直接复制粘贴参数占位符
ExecuteScalar 和 ExecuteReader 也要参数化吗
要。只要 SQL 字符串里包含任何用户输入，不管执行什么方法，都得参数化。很多人以为只有 ExecuteNonQuery（增删改）危险，其实 SELECT 泄露数据、ExecuteScalar 返回伪造 ID、ExecuteReader 被注入 UNION SELECT 都是高危操作。
典型错误：用 ExecuteScalar 查登录态，写成 "SELECT id FROM users WHERE email = '" + email + "' AND pwd = '" + pwd + "'" —— 输 admin@example.com' AND 1=1 UNION SELECT 'hacked'-- 就能绕过验证。
-
ExecuteScalar示例：cmd.CommandText = "SELECT COUNT(*) FROM logs WHERE level = @level AND ts > @since"; cmd.Parameters.Add("@level", SqlDbType.VarChar).Value = inputLevel; -
ExecuteReader里别在循环中反复cmd.Parameters.Clear()再 Add——用cmd.Parameters["@id"].Value = nextId复用更高效 - ORM 如 Dapper、EF Core 默认参数化，但手写
connection.Query("SELECT * FROM t WHERE id = " + id)就破防了
哪些地方「看起来像参数化」其实没用
用 ORM 的 Where(x => x.Name == input) 是安全的，但一旦切到原生 SQL，哪怕只拼一个表名、字段名或 IN 列表，就退回高危区。这类“半参数化”最骗人。
性能影响：预编译本身几乎无开销，但滥用字符串拼接 + 参数混合（比如 "SELECT * FROM " + table + " WHERE id = @id"）会导致每次 SQL 文本不同，数据库无法复用执行计划，缓存命中率暴跌。
-
IN列表必须展开为独立参数：WHERE id IN (@p1, @p2, @p3)，不能传一个逗号字符串再FIND_IN_SET拼接 - 表名、列名、排序方向（
ASC/DESC）无法参数化，必须走白名单校验：if (!new[] { "created_at", "score" }.Contains(sortField)) throw ... - MyBatis 的
${xxx}是字符串替换，#{xxx}才是参数化——看错符号等于没防
最容易被忽略的是日志记录和调试输出：把原始 SQL 拼接后打到日志里，等于把攻击 payload 直接写进磁盘。查问题时宁可用参数化后的 cmd.Parameters 逐个打印值，也别拼完整语句。
