IN子句参数超限应拆分批次处理，反射无法获取泛型类型需显式传入Class，集合须转ArrayList保序，禁用FIND_IN_SET替代IN，优先用临时表+JOIN处理大数据集。
IN子句参数数量超限导致 PreparedStatement 报错
数据库驱动（比如 MySQL Connector/J）对 PreparedStatement 中的参数个数有限制，PostgreSQL 默认也限制 65535 个绑定变量。反射生成 IN 列表时若不控制长度，很容易触发 SQLSyntaxErrorException: Too many parameters 或类似错误。
实操建议：
- 用反射拿到集合后，先检查
collection.size()，超过 1000 就拆分（多数数据库安全阈值在 1000–2000） - 不要直接拼接
"?," + "?," + ...，而应按批次生成多个IN子句，再用OR连接（如id IN (?) OR id IN (?)） - 避免在循环里反复调用
setObject(i, value)——反射取值本身快，但 JDBC 绑定开销大，批量处理更稳
Java 反射获取泛型集合元素类型失败
反射读不到 List<string></string> 里的 String，因为泛型擦除后只剩 List；若后续要校验参数类型或做 SQL 类型映射（比如把 LocalDateTime 转成 TIMESTAMP），类型信息就丢了。
实操建议：
- 传入集合时一并传入
Class<T>，比如buildInClause(list, String.class) - 用
Field.getGenericType()+ParameterizedType解析仅适用于字段或方法签名，不适用于运行时传入的局部变量 - 如果集合为空，别依赖反射猜类型——直接抛
IllegalArgumentException，比生成空IN ()导致语法错误更早暴露问题
生成的 IN 参数顺序与原始集合不一致
反射遍历 Collection 本身不保证顺序，尤其当传入的是 HashSet 或并发集合时，SQL 中参数绑定顺序错乱，可能让 WHERE id IN (?, ?, ?) 对应到错误的值，查出脏数据。
实操建议：
- 统一转成
ArrayList再处理：new ArrayList<>(collection) - 对
Map类型，明确用map.keySet()还是map.values()，别靠反射自动选 - 如果原始集合是自定义类且重写了
equals/hashCode，确保它没干扰迭代顺序——比如某些树形结构 map 实现会按 key 排序
MySQL 的 FIND_IN_SET 不适合替代 IN + 参数化
看到 IN 参数太多，有人会想用 FIND_IN_SET(?, ?) 把整个列表塞进一个字符串参数，比如 FIND_IN_SET(id, '1,2,3,4')。这看似绕过参数限制，实则破坏索引、无法预编译、还容易被注入（如果字符串未清洗）。
实操建议：
-
FIND_IN_SET只接受字面量字符串，?绑定进去会被当做一个整体字符串，不是逗号分隔列表 - MySQL 8.0+ 支持
JSON_CONTAINS，但要求字段是JSON类型，且性能不如原生IN索引查找 - 真要硬扛大数据集，优先考虑临时表 +
JOIN，而不是在 SQL 字符串里做文章
最麻烦的不是怎么生成那串 ?, ?, ?，而是得时刻盯着集合从哪来、有没有被中间件改过、是否可能为 null、以及数据库到底认不认你这个参数序列——这些地方一松劲，SQL 就在生产里静默错配。
