如何解决SQL中的IN子句注入难题：动态构建参数化占位符列表
为什么不能直接拼接 IN 列表
SQL注入的风险，往往就藏在看似无害的字符串拼接里。举个例子，如果写成 WHERE id IN ('" + ids.join("','") + "') 这种形式，一旦传入的 ids 来自不可信的用户输入（比如 ["1", "2', DROP TABLE users--"]），整个查询就彻底失控了。数据库引擎不会把引号里的内容当作普通数据值来处理，而是会将其作为SQL语法的一部分执行，后果可想而知。
还有一个更隐蔽的问题：即便输入看起来“干干净净”，数据类型不一致也可能导致隐式转换失败，或者让数据库索引失效。比如说，id 字段明明是整型，但拼接进去的却是带引号的字符串，MySQL很可能因此放弃使用索引，转而进行低效的全表扫描。
IN 子句必须用参数化，但 ? 占位符不能动态增减
绝大多数数据库驱动（比如 Python 的 sqlite3、psycopg2，或者 Node.js 的 pg）都不支持一个 ? 占位符对应多个值。如果你试图写成 WHERE id IN (?) 然后把一个数组传进去，通常会收到类似 bind parameter N not usable as scalar 的错误，或者驱动干脆只认数组的第一个值，直接忽略后面的。
那正确的做法是什么？其实很简单：根据实际数据数组的长度，**动态生成对应数量的 ? 占位符**，然后再把这些值一一绑定上去。来看个例子：
const ids = [1, 5, 9, 22];
const placeholders = ids.map((_, i) => '?').join(',');
// → 得到 '?, ?, ?, ?'
const sql = `SELECT * FROM users WHERE id IN (${placeholders})`;
// 执行查询时，将数组 [1, 5, 9, 22] 作为参数传入，由驱动完成原生绑定
这里的关键在于：placeholders 字符串的拼接完全不涉及任何用户数据，是绝对安全的；真正进入数据库的只有后续绑定的那些值。
空数组和超长列表的边界情况必须显式处理
这是两个高频的“翻车”点，稍不注意就会掉坑里：
- 空数组：直接生成
IN ()是语法错误。这时候通常需要退化成WHERE 1=0这样的永假条件，或者改用NOT EXISTS之类的逻辑来重写查询。 - 超长列表：数据库对参数数量是有限制的。比如 PostgreSQL 默认限制 65535 个参数，MySQL 则受
max_allowed_packet和预处理语句缓存的影响。一旦列表超长，要么得拆分成多个批次查询，要么就得考虑改用临时表来关联数据。
一个包含了空数组防护的示例代码如下：
if (ids.length === 0) {
return db.all('SELECT * FROM users WHERE 1=0');
}
const placeholders = Array(ids.length).fill('?').join(',');
return db.all(`SELECT * FROM users WHERE id IN (${placeholders})`, ids);
ORM 和查询构建器里的等效操作不是银弹
像 Knex、Drizzle、Django ORM 这些工具，确实提供了 .whereIn() 这类便捷方法，底层原理也是动态生成占位符。但是，别以为用了它们就高枕无忧了，有几个细节尤其要注意：
- 它们通常不会自动处理空数组。Django ORM 可能会抛出
EmptyResultSet异常，而 Knex 可能只是默默地返回一个空结果集，如果不仔细测试，很容易遗漏这个边界情况。 - 框架也有自己的限制。例如，Drizzle 的
inArray()在 SQLite 下，如果项数超过 999，就会报错，需要手动进行分块处理。 - 数据库配置也可能带来意外。比如使用 TypeORM 的
find({ where: { id: In([...]) } })时，在 PostgreSQL 上可能会触发预处理语句模式，而某些连接池（如 pgBouncer 在事务模式或语句模式下）可能并不支持这种模式。
说到底，这些框架只是帮你完成了“生成占位符字符串 + 绑定值”这套动作。校验数组长度、处理空值、适配不同数据库方言的逻辑责任，仍然在开发者肩上。
最容易被忽略的一点是数据库方言的差异。SQLite 允许 IN (?, ?,) 末尾多一个逗号，PostgreSQL 可绝对不允许；MySQL 对 IN 子句内的最大项数相对宽容，但其排序和去重的具体行为，可能与 PostgreSQL 存在差异。千万别抱着“在一个数据库上跑通了，就能放之四海而皆准”的想法。
