SQL参数化查询必须使用驱动层预编译机制（如psycopg2的%s、JDBC的?、pg的$1），仅允许替换值，字段名/表名需白名单校验后拼接；动态条件应服务端构建SQL并严格匹配参数数量。
SQL参数化查询到底要怎么写才安全
不加参数化的 SQL 拼接，等于把数据库钥匙塞进用户输入框里。所有语言里，SELECT * FROM users WHERE name = ' + user_input 这种写法，哪怕加了单引号包裹，只要没走预编译机制，就是 SQL 注入高危区。
真正安全的参数化，必须依赖数据库驱动层的预编译支持，不是字符串替换，也不是手动加引号。
- Python 的
psycopg2用%s占位，传参用元组或字典（cursor.execute("SELECT * FROM t WHERE id = %s", (123,))） - Java 的 JDBC 用
?占位，配合PreparedStatement（stmt.setInt(1, 123)） - Node.js 的
pg模块用$1、$2（client.query("SELECT * FROM t WHERE id = $1", [123])） - 切忌用字符串格式化（
f"WHERE name = '{name}'"或.format()）代替参数化
WHERE 条件字段名/表名能参数化吗
不能。SQL 参数化只允许替换「值」，不允许替换标识符（字段名、表名、排序方向、LIMIT 数量等）。这是协议层面限制，不是语法糖能绕过的。
常见错误现象：cursor.execute("SELECT * FROM ? WHERE ? = ?", ("users", "status", "active")) —— 这会直接报错，因为第一个和第二个 ? 不被解析为标识符。
- 动态字段/表名必须白名单校验后拼接（例如从预设的
["users", "orders"]中匹配） - 排序字段同理，
ORDER BY <code>status要先判断是否在["id", "status", "created_at"]内 -
LIMIT ? OFFSET ?是合法的（值可参数化），但LIMIT ?后面不能跟表达式，如LIMIT ? * 2会失败
多个动态条件怎么写才不炸掉 SQL 结构
拼接 WHERE 子句时硬写 AND status = ? AND category = ? 很容易漏掉空值判断，导致查出意外数据，或者因 NULL 值逻辑崩坏。
关键不是“怎么拼”，而是“怎么让条件真正生效或失效”。别用 AND (? IS NULL OR status = ?) 这种写法——它会让索引失效，且语义模糊。
- 服务端按需构建 SQL：收集非空参数，动态生成
WHERE status = ? AND category = ?，空值直接跳过 - 用数组存参数值，确保占位符数量和参数数量严格一致（
params = []，每加一个条件就params.append(val)） - 如果必须统一 SQL 结构（比如 ORM 预编译缓存要求），可用
COALESCE(?, column) = column，但注意性能影响
PostgreSQL 的 $1 和 MySQL 的 ? 在批量插入时有啥区别
本质都是位置参数，但批量执行时行为不同，容易踩坑。
MySQL 的 executemany("INSERT INTO t VALUES (?, ?)", [(1,'a'), (2,'b')]) 是真批量，一条语句发多个值；PostgreSQL 的 execute_many（或原生 execute_batch）默认仍是逐条发送，除非显式启用 execute_batch 并配置 page_size。
- MySQL 批量插入用
VALUES (?, ?), (?, ?)形式，参数是一维列表展平（[1,'a',2,'b']），不是二维 - PostgreSQL 推荐用
execute_batch+page_size=100控制内存，避免单次传太多参数触发ERROR: bind message supplies 1000 parameters, but prepared statement "" requires 2 - SQLite 不支持多值 INSERT 的参数化，必须拆成多条
INSERT或改用executemany
动态值查询最麻烦的从来不是语法，而是边界控制——什么时候该拼，什么时候该抛错，什么时候该 fallback 到全表扫描。这些决策点藏在业务逻辑里，没法靠一个 ? 自动解决。
