直接拼接IN条件字符串可行但需预处理，因?占位符仅支持单值；传入'1,2,3'会被当作一个字符串而非三个独立值；应手动构造IN子句并用QUOTE()转义字符串，或使用临时表、FIND_IN_SET、JSON_TABLE（MySQL 8.0+）等安全方案。
直接拼接 IN 条件字符串是可行的，但必须用字符串拼接 + 预处理执行，不能直接把变量塞进 IN (?) 占位符里——因为 ? 只能代表单个值，无法展开为多个值列表。
为什么不能直接用 IN (?) 传入逗号分隔的字符串
当你写 WHERE id IN (?) 并用 EXECUTE stmt USING @ids 传入 '1,2,3'，MySQL 实际执行的是 WHERE id IN ('1,2,3')，即把整个字符串当做一个值匹配，不是三个独立整数。结果永远为空或误匹配。
- 错误示例：
SET @ids = '1,2,3'; PREPARE stmt FROM 'SELECT * FROM users WHERE id IN (?)'; EXECUTE stmt USING @ids; - 正确思路：把
IN后面的整个值列表作为字符串拼进 SQL，再预处理执行
如何安全拼接 IN 子句（含字符串防注入）
核心是手动构造 IN ('a','b','c') 或 IN (1,2,3) 片段，对每个值做转义，避免 SQL 注入。数值类型可直接拼，字符串类型必须用 QUOTE() 包裹。
-
QUOTE('O''Reilly')→'O''Reilly'（自动双写单引号） - 不要用
CONCAT("'", val, "'")，它不处理引号逃逸 - 拼接前先检查输入是否为空，空时跳过该条件或设默认值
示例片段：
SET @in_list = '';
IF input_names IS NOT NULL AND input_names != '' THEN
-- 假设 input_names 是逗号分隔字符串，如 'Alice,Bob,Charlie'
SET @in_list = CONCAT('name IN (',
REPLACE(QUOTE(input_names), ',', CONCAT(',', QUOTE(','))),
')');
-- ❌ 上面只是示意；实际需拆分字符串（MySQL 8.0+ 用 JSON_TABLE，5.7 用辅助函数或循环）
END IF;MySQL 5.7 中实用的替代方案：用临时表或 FIND_IN_SET
原生不支持数组参数，又不想写复杂拆分逻辑时，两个更稳的选择：
- 用
FIND_IN_SET(id, @id_list)：仅适用于数值 ID，且@id_list是逗号分隔字符串（如'1,2,3'），性能较差，无法走索引 - 先插入临时表：
CREATE TEMPORARY TABLE tmp_ids (id INT); INSERT INTO tmp_ids VALUES (1),(2),(3);，再JOIN或WHERE id IN (SELECT id FROM tmp_ids)，可走索引、易维护
临时表方式虽多两步，但在生产环境更可控，尤其当 IN 列表可能上百项时。
MySQL 8.0+ 推荐：用 JSON 参数 + JSON_TABLE 拆解
如果确定运行在 MySQL 8.0.4+，直接传 JSON 数组最干净：
CREATE PROCEDURE get_users_by_ids(IN json_ids JSON)
BEGIN
SET @sql = '
SELECT u.* FROM users u
INNER JOIN JSON_TABLE(?, "$[*]" COLUMNS(id INT PATH "$")) jt
ON u.id = jt.id';
SET @params = json_ids;
PREPARE stmt FROM @sql;
EXECUTE stmt USING @params;
DEALLOCATE PREPARE stmt;
END调用：CALL get_users_by_ids('[1,2,3,4]'); 或 CALL get_users_by_ids('["alice","bob"]');。JSON_TABLE 自动处理类型和转义，比手撕字符串可靠得多。
真正容易被忽略的是：动态 IN 的边界处理——空输入、单值、超长列表（超过 max_allowed_packet）、字符集不一致导致的 QUOTE() 异常。别只测“有数据”的 case，务必验证 NULL 和空字符串传入时存储过程是否静默失败或返回全表。
